Críticas a la Orientación de Objetos

Publicado: agosto 17, 2006 en Ingenieria de Software

A continuación se presentan algunas consideraciones respecto a cómo el MOO es presentado mayoritariamente en la literatura. Muchos autores afirman incluso la conveniencia de usar orientación a objetos en el modelado conceptual. Estas afirmaciones serán analizadas críticamente en las siguientes secciones.

  1. Naturalidad.- La esencia del paradigma de la orientación a objetos y más específicamente, del MOO, es la visión de la realidad compuesta por objetos. Frecuentemente se afirma que esta visión es “más natural” que una visión funcional o comportamental. Por ejemplo, en el ámbito de la ingeniería de negocios, algunos autores, sugieren utilizar el modelo de objetos para diseñar negocios dada esta aparente naturalidad que facilitaría la comunicación
  2. Encapsulamiento .-

    En Informática existe una fuerte tendencia a forzar la realidad modelada a una conceptualización originada de la construcción de software. Por ejemplo, el MOO se sustenta en el encapsulamiento que propone separar los aspectos externos de los internos. Los aspectos externos son cono-cidos por otros objetos, en cambio los aspectos internos son de conocimiento exclusivo del objeto propietario. De esta forma, los objetos son autocontenidos y no comparten ningún tipo de dato que no sea solicitado en las colaboraciones con otros objetos. La cuestión es la siguiente: ¿tiene sentido encapsular en el nivel de abstracción requerido en elmodelado conceptual? Dado que la mayor ven-taja del encapsulamiento se revela en la fase de implementación, ¿qué beneficios se podrían esperar
    del encapsulamiento en el modelado conceptual? ¿encapsular en el modelado conceptual no representaría introducir prematuramente rasgos de implementación?.
  3. Continuidad Estructural.-

    La continuidad estructural, en las sucesivas fases del ciclo de vida orientado a objetos, es comúnmente indicada como una ventaja. El gap semántico1se vería dismi-nuido: por ejemplo, los objetos identificados en el dominio del problema serían mapeados directa-mente en los objetos especificados en el dominio de la solución durante el diseño. Lo mismo sucede-ría con estos objetos al ser mapeados en los objetos codificados de la implementación. Se puede afirmar entonces, que el MOO sería ventajoso si tanto el diseño como la implementación fueran también conducidos bajo este mismo paradigma. Sin embargo, el beneficio de la continuidad estructural no debería tener el costo de colocar el MOO más cerca del diseño orientado a objetos. El modelado conceptual, en la perspectiva de la ingeniería de requerimientos, debe ser orientado al problema (realidad) y no a la solución concreta (implementación orientada a objetos).

  4. Transición al Diseño.-

    La confusión existente entre lo que es el análisis y el diseño orientados a objetos, es decir, la poca claridad en los límites entre estas dos fases es indicada en la literatura. El principio de la ingeniería de software de que el análisis debe ser declarativo con relación al diseño, es decir, que describe qué debe hacer el sis-tema en contraste con el diseño que establece cómo ha de hacerse, no ocurre en la orientación a objetos. En la práctica, los modelos orientados a objetos del análisis son sólo menos detallados que los del diseño o sólo constituyen el “centro” del modelo de diseño; así la pretensa declaratividad no es alcanzada. De esta forma, el MOO puede entenderse como un diseño preliminar, porque una vez que los requerimientos son entendidos, éstos se organizan en un modelo que sirve como estructura interna del sistema a ser diseñado.La orientación a objetos debe ser considerada entonces como una decisión de diseño e implementación y no como una decisión de modelado conceptual o de análisis de requerimientos.Por lo anterior, los términos análisis y orientación a objetos en realidad se contraponen. La noción de análisis como descomposición y examen crítico con el fin de aumentar la comprensión no alcancalza con las ideas de síntesis (encapsulamiento de atributos y operaciones en los objetos) y de alter-nativa de diseño e implementación de la orientación a objetos.Una forma de resolver este problema es creando mecanismos que permitan postergar el en-capsulamiento tanto cuanto sea posible. En otras palabras, modelar el dominio del problema fuera del paradigma de la orientación a objetos, con suficiente poder de expresión y flexibilidad para poder derivar modelos orientados a objetos con relativa facilidad, si la implementación desea ser realizada bajo este paradigma. De esta forma, el modelado concluye antes de introducirse el encapsulamiento, punto en el cual comienza el diseño orientado a objetos3.En este sentido, el modelo de casos de uso (use case), propuesto por Jacobson, puede utilizarse previo a la construcción de modelos de objeto. Un modelo de casos de uso representa una manera específica de usar el sistema: a través de la ejecución de alguna parte de su funcionalidad. Cada caso de uso describe un escenario completo de eventos iniciados por un actor (o papel de usuario) y especifica la interacción que ocurre entre el actor y el sistema. Corresponde así a una visión externa del sistema, que no se construye bajo el paradigma de la orientación a objetos.

Conclusiones 

Bajo los argumentos aquí presentados, el MOO debe ser considerado como una alternativa más para hacer frente al análisis de sistemas, con una fuerte restricción impuesta a priori de implementar orientado a objetos. Con el fin de obviar esta restricción se sugiere modelar usando técnicas que posterguen el encapsulamiento, es decir, que permitan modelar fuera del paradigma de la orientación a objetos y que, eventualmente y si así se desea, sea posible realizar un mapeamiento a un modelo de objetos, momento en el cual se iniciaría el diseño orientado a objetos. Esta evolución del pensamiento sobre el MOO, se ve reflejada en la reciente propuesta de utilizar el modelo de casos de uso como conductor del proceso de desarrollo de software orientado a objetos, es decir, un modelo no orientado a objetos sirve como guía o marco para el resto de los modelos orientados a objetos.En el caso de optar por un análisis orientado a objetos, se debe estar consciente de que en realidad se está construyendo un modelo de diseño inicial o preliminar del sistema. Los términos para el análisis orientado a objetos se contraponen a los del diseño orientado a objetos, se reconocienda en ambos el carácter de diseño.

comentarios
  1. julian dice:

    solo nesesito ejemplos no tanta lectura porque nesesito algo especifico en realidad esta bien la conclusion pero no esta especificada

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s