1. República Bolivariana de Venezuela<br />Ministerio del Poder Popular Para la Defensa<br />Universidad Nacional Experimental Politécnica de la Fuerza Armada<br />Carabobo-Guacara<br />Diseño Orientado a Objeto<br />Integrantes<br />Mendoza Arlic <br /> Meléndez Hengerber Montaño Yaritrini<br />Palmera José<br />Sección: 003 Ing. Sistema<br />Guacara 14 de julio del 2010<br />Introducción<br />Los conceptos fundamentales del diseño y la programación orientada a objetos han sido desarrollados hace más de treinta años, pero en los últimos diez ha tenido un el diseño orientado a objetos puede ser analizado desde dos puntos de vista, el diseño de la arquitectura (alto nivel) o el diseño de clases (bajo nivel). Se descarta el punto de vista de la arquitectura, puesto que es muy dificultoso medirlo a partir del código y no existe un consenso de expertos sobre calidad de diseño de la arquitectura de un producto como para tomarlo como punto de referencia, el polimorfismo y herencia son fundamentales en nuestro diseño.<br />Bertrand Meyer [1998], en un artículo sobre “El rol de las métricas orientadas a objetos” que ha servido de marco de referencia para el planteo de este trabajo, resalta que “Existe, de hecho una extensiva literatura de métricas de software, inclusive para desarrollos orientados a objetos, pero sorpresivamente pocas publicaciones son usadas en los proyectos actuales”. Coincidiendo con la observación, se han planteado métricas que son aceptadas por la comunidad de desarrolladores orientados a objetos, cuya medición puede realizarse con la simple lectura del código. Para lograr la aceptación de los desarrolladores se busca un mapeo directo entre las métricas y los conceptos esenciales de diseño4, o sea, un conjunto de métricas que en una lectura rápida permita hacer una validación intuitiva de éstas, con el objetivo de no dudar de su consistencia teórica desde un primer momento<br />Diseño Orientado a Objetos<br />Qué es Orientado a Objetos<br />Es una forma de pensar -una forma de modelar una solución a un problema, es una extensión a las metodologías de desarrollo previas, semejantes a la programación estructurada, esta reconoce que los procesos naturales de pensamiento humano obtienen muchas ventajas evolucionarías, y por lo tanto trata de darle un adecuado soporte. <br /> <br />Por qué la orientación a objetos<br />Por la estabilidad del modelado respecto a las entidades del mundo real, y la construcción iterativa facilitada por el acoplamiento débil entre componentes; tratando la posibilidad de reutilizar elementos entre desarrollos, y Por la simplicidad del modelado en base a 5 conceptos fundamentales (objetos, mensajes, clases, herencia y polimorfismo). <br />Qué es un objeto<br />Un objeto es aquel que posee estado, comportamiento, e identidad; la estructura y comportamiento de objetos similares son definidos en su clase común; los términos instancia y objeto son intercambiables<br />Diseño Orientado a Objetos<br />Se define como un diseño de sistemas que utiliza objetos auto-contenidos y clases de objetos.<br />También el diseño Orientado a Objetos (DOO) difiere considerablemente del diseño estructurado ya que en DOO no se realiza un problema en términos de tareas (subrutinas) ni en términos de datos, sino (como ya se vio en la introducción) se analiza el problema como un sistema de objetos que interactúan entre sí.<br />Un problema desarrollado con técnicas orientadas a objetos requiere, en primer lugar saber cuales son los objetos del programa. Como tales objetos son instancias de clases, la primera etapa en el desarrollo orientado a objetos requiere de la identificación de dichas clases (atributos y comportamiento), así como las relaciones entre éstas y su posterior implementación en un lenguaje de programación.<br />Existen numerosos métodos de diseño orientado a objetos: Booch, Yourdon-Coad,<br />Martín, Shlaer & Mellor, Rumbaugh, por citar algunos. Pero en general como ocurre en cualquier proyecto estructurado, un proyecto software OO se compone de las siguientes etapas:<br /> Análisis Orientado a Objetos (AOO)<br /> Diseño Orientado a Objetos (DOO)<br />Programación Orientada a Objetos (POO)<br />Aunque no siempre están bien delimitadas las etapas de análisis y diseño en la<br />OO, se pueden sintetizar de alguna forma las ideas claves de las distintas tecnologías existentes dentro del desarrollo orientado a objetos al que denominaremos diseño.<br />Métodos de Diseño Orientado a Objetos<br />Algunos métodos basados en funciones (método de Yourdon) han sido adaptadas al diseño orientado a objetos. <br />Otros métodos como el método de Booch han sido específicamente desarrolladas específicamente para el Diseño Orientado a Objetos, este de método de Booch considera que las etapas del proceso en un desarrollo orientado a objetos son:<br />Identificar las claves y objetos en un nivel dado de abstracción<br />Identificar la semántica de estas clases y objetos<br />Identificar las relaciones entre clases y objetos<br />Especificar la interfaz y la implementación de estas clases y objetos<br /> Estas etapas suelen seguirse por la mayoría de los métodos de diseño OO existentes. De hecho, para los sistemas orientados a objetos se define el siguiente diseño en pirámide que contempla el método de Booch.<br />El Diseño Orientado a Objetos es un método de diseño desarrollado para soportar la programación en Ada.<br />JSD (Jackson system development) tiene una cierta orientación a objetos pero no<br />contiene información sobre estados entidad<br />Características principales del Diseño Orientado a Objetos:<br />Los objetos son abstracciones del mundo real o entidades del sistema que se administran entre ellas mismas.<br />Los objetos son independientes y encapsulan el estado y la representación de Información.<br />La funcionalidad del sistema se expresa en términos de servicios de los objetos<br />Las áreas de datos compartidas son eliminadas. Los objetos se comunican mediante paso de parámetros<br />Los objetos pueden estar distribuidos y pueden ejecutarse en forma secuencial o en<br />Paralelo<br />Ventajas del Diseño Orientado a Objetos:<br />Fácil de mantener, los objetos representan entidades auto-contenidas<br />Los objetos son componentes reutilizables<br />Para algunos sistemas, puede haber un mapeo obvio entre las entidades del mundo real y los objetos del sistema<br />EL DISEÑO:<br />Bertrand Meyer sugiere los siguientes criterios para poder juzgar la capacidad que pose un método de diseño en poder lograr ciertos elementos importantes tales como la modularidad:<br />Descomponibilidad.- Facilidad con la cual un método de diseño ayuda al diseñador a descomponer un gran problema en subproblemas más sencillos de resolver.<br />Componibilidad.- Grado con el cual un método de diseño asegura que los componentes de un programa (módulos), una vez diseñados y construidos, pueden rehusarse para crear otros sistemas.<br />Comprensibilidad.- Facilidad de comprensión de un componente de programa sin referencia a otra información o módulos.<br />Continuidad.- Facilidad de hacer pequeños cambios en un programa y hacer que estos se manifiesten por sí mismos en cambios correspondientes solamente en no o unos pocos módulos más.<br />Protección.- Característica arquitectónica que reducirá la propagación de efectos colaterales si ocurre un error en un módulo dado.<br />Éstos criterios y principios de diseño presentados por Meyer pueden aplicarse a cualquier método de diseño (incluyendo diseño estructurado), no obstante el método de diseño orientado a objetos alcanza cada uno de los principios de manera más eficiente que otros enfoques y el resultado final es una arquitectura modular que permite cumplir con todos los principios de modularidad de una manera más eficiente.<br /> El DOO aplica diseño de datos (cuando se representan atributos), diseño de interfaces (cuando se presenta el intercambio de mensajes) y diseño procedimental (en el diseño de operaciones), no obstante el diseño arquitectónico es diferente.<br />Clases<br />Una clases, cuando el diseñador se encuentra con un conjunto de objetos que comparten los mismos atributos y el mismo comportamiento (por ejemplo, cada uno de los empleados de una empresa donde se está construyendo un sistema de jornales; cada uno de los productos que produce una fábrica donde se está realizando un sistema de control de stock), utiliza el mecanismo de clasificación para abstraer estas propiedades y comportamiento. De esta forma, la construcción de la clase le permite generar una suerte de “plantilla” a partir de la cual puede construir los objetos que forman parte del sistema. Esta “plantilla” es un modelo recortado que toma únicamente las propiedades y comportamiento que le interesan para el sistema que está modelando en ese momento.<br />En el proceso de clasificación nos encontramos frecuentemente con clases que comparten algunas características comunes. Por este motivo, en los ambientes de objetos podemos construir clases superiores o abstractas, que encapsulan el comportamiento común, para que el conjunto de clases con características comunes hereden de la clase abstracta dichas propiedades<br />Polimorfismo<br />Quiere decir que el que envía un estímulo no necesita conocer la clase de la instancia receptora. La instancia receptora puede pertenecer a una clase arbitraria… el Polimorfismo quiere decir que instancias diferentes pueden ser asociados, y que estas instancias pueden pertenecer a clases diferentes…<br />Un estímulo puede ser interpretado de formas diferentes, dependiendo de la clase del receptor. Es, por lo tanto, la instancia que recibe el estímulo la que determina su interpretación, y no la instancia transmisora. A menudo, se dice que el polimorfismo, significa que una operación puede ser implementada en formas diferentes en clases diferentes. Esto es en realidad sólo una consecuencia de lo dicho y no el polimorfismo en sí mismo<br />Herencia<br />Es el mecanismo por el cual una clase recibe comportamiento y propiedades de una clase superior<br />Polimorfismo y Herencia<br />Un diseño orientado a objetos el tipo de cada clase debería adecuarse al tipo de su superclase. En otras palabras, la jerarquía de herencia de la clase o subclase debería seguir el principio de conformidad de tipo. La razón es que para explotar el polimorfismo sin esfuerzo, debemos ser capaces de pasar los objetos de una subclase en vez de los objetos de una superclase.<br />Para asegurar la compatibilidad con el tipo en la subclase, en primer lugar se necesita que el invariante de la clase sea al menos tan fuerte como el de superclase. El invariante de la subclase puede ser más fuerte que el invariante de la superclase. En segundo lugar es necesario asegurarse que las siguientes restricciones en las operaciones se cumplan:<br /> Cualquiera de las operaciones de la superclase tiene una operación correspondiente en la subclase con el mismo nombre y firma.<br /> Cualquier precondición de operación no es más fuerte que la correspondiente operación en la superclase. O sea que, el rango de la precondición de la operación en la subclase puede ser más amplio que la precondición de la operación de la superclase.<br />Cualquier postcondición de operación es al menos tan fuerte como la correspondiente operación en la superclase. O sea que el rango de la postcondición de la operación en la subclase puede ser más pequeño que el rango de la postcondición de operación en la superclase.<br /> Método de Inferencia<br />En el primer caso tenemos un modelo que hace hincapié en procesos de inferencias inductivos, donde a partir de un conjunto de hechos similares, defino una regla común que explica todos estos hechos. En el segundo caso, los teoricistas ponen el acento en procesos deductivos, que a partir de la regla o teoría, se define el comportamiento de los hechos observables.<br />A simple vista podemos ver que ninguno de los dos caminos es posible: nunca realizamos observaciones en un marco “aséptico”, sin vivencias y conocimientos previos que obliguen a la observación a dirigirse a ciertos aspectos y no otros. Y tampoco generamos mágicamente teorías a partir de la nada, que luego sean verificadas en los hechos. En sí, ninguno de los dos es un punto de partida: la combinación de prototeorías y protoobservaciones son las que nos permiten, en un camino oscilante de uno a otro, generar el conocimiento científico. A este conocimiento básico, que contiene en forma “primitiva” a la teoría y la observación, Ladriere la llamó precomprensión modelizante. A partir del mismo, mediante dos nuevas formas de inferencia, partimos de este conocimiento en formación o génesis y nos acercamos a lo que llamamos estructura. Estas formas de inferencia son la analogía y la abducción.<br />La analogía nos permite transpolar conocimientos de objetos o campos distintos a nuestro campo de estudio. Por ejemplo, en investigaciones sobre visión global en ambientes dinámicos llevados a cabo en nuestro centro, partimos de la idea gestáltica del proceso por el cual nuestro cerebro completa la imagen aún teniendo información incompleta de la misma. De esa manera, comenzamos nuestras investigaciones con algoritmos estadísticos que, con poca información de visión, permitían reconstruir los objetos en un tiempo mínimo.<br />La abducción nos permite inferir una hipótesis interpretativa de la causa del rasgo encontrado al relacionarlo con cierta regla que ya poseemos. Por ejemplo, si en nuestra detección de figuras en una imagen utilizando métodos estadísticos, nos encontramos que ante determinada toma de datos el error de detección es alto, arriesgaremos por abducción que la elección de los datos para el reconocimiento ha sido errónea. En este caso, el rasgo (error alto en la detección de la figura) junto a la Regla (con una muestra de distribución uniforme del 3% de los puntos de un cuadrado detectamos la posición de la figura con un porcentaje de error bajo) nos permiten abducir que el Caso (la muestra tomada de la imagen) ha tenido un problema de sesgo, es decir, una muestra con distribución no uniforme o un número menor al 3% de los puntos del cuadrado.<br />Procesos de Inferencia<br />Deducción<br />Probablemente sea el menos constructivo pero a su vez el proceso más utilizado en el diseño. Cuando creo un objeto de una clase, al pertenecer dicho objeto a la clase, puedo deducir cuáles son las propiedades y mensajes a los cuales responde el objeto.<br />Es decir, la definición de la clase es la Regla de mi proceso de inferencia, el objeto que yo creé es el Caso, y los rasgos son las propiedades y comportamiento que el objeto me ofrecerá. Veamos un ejemplo: tenemos la clase Alumno, que tiene las propiedades apellido, nombre, dirección, teléfono, notas, presentismo, etc; además le puedo enviar el mensaje nota informándole en qué materia se sacó la nota, cuándo y cuál es la nota.<br />Cuando creamos un objeto de esa clase, sabemos que el objeto tiene las propiedades y responde a los mensajes que su clase tiene definidos. Aún más, si modificamos la definición de la clase, automáticamente todos los objetos creados de la clase sufrirán la misma modificación.<br />Inducción<br />Cuando el diseñador realiza la primera aproximación con la documentación del análisis, comienza por la búsqueda de los objetos que dicha documentación describe. En su lectura, encuentra que cada objeto presenta ciertas propiedades y comportamientos, y que muchos de ellos los comparten. Por ejemplo, en la descripción del análisis de un sistema de administración de alumnos de una facultad, encontramos un alumno que se inscribe a un determinado tipo de curso. En otro momento de la descripción encontramos a otro alumno que paga su cuota. De esta manera comienzo a concluir que hay un conjunto de objetos que comparten ciertos atributos y que responden a los mismos mensajes: he descubierto una Clase. Esta clase no presenta todas las características de los objetos del mundo real; sólo modelará aquellas que sean de incumbencia para el sistema que se está construyendo.<br /> A partir de los diferentes Casos (los objetos que describe el análisis) y de los rasgos que cada objeto ha presentado.<br />Analogía<br />Los dos procesos anteriores serían imposibles si partimos de la nada. Así como un arquitecto no construye una casa a partir de arena y piedra, los diseñadores no construyen desde clases atómicas. Siempre que el diseñador lee la documentación del análisis, tiene en su mente el bagaje de las lecturas previas y de los diseños anteriormente realizados. Es más, todos los ambientes de programación orientada a objetos, ofrecen al diseñador un conjunto muy importante de clases ya creadas e implementadas, las cuales puede utilizar para heredar o para componer. Los procesos de herencia y de composición mismos se presentan como una analogía a lo ya construido.<br />Por ejemplo, cuando nos encontramos con la necesidad de manipular un conjunto de objetos, sabemos que en las clases ya implementadas tenemos algunas de ellas que nos permiten trabajar con colecciones: colecciones indexadas y no indexadas, bolsas conjuntos, colecciones con índices de dos dimensiones, etc. A partir de este conocimiento, decidiré si utilizo directamente alguna de ellas, si creo una subclase de una de dichas clases modificando y especificando su comportamiento, o si me conviene realizar una clase completamente desde cero (lo cual es muy poco común).<br />Abducción<br />La abducción en muchos casos tiene un fuerte vínculo con la analogía. Cuando en el diseño de objetos, nos encontramos con algunos objetos que presentan determinadas características y comportamientos, y conociendo las clases preexistentes que me proporciona el ambiente, es habitual que utilicemos la abducción. Es decir, a partir de ciertos rasgos del objeto, y la definición de una determinada clase (Regla), suponemos que ese objeto pertenece a la clase (Caso) y por lo tanto, automáticamente el objeto se enriquece con las demás propiedades y comportamiento de la clase. Puede ocurrir que en ese momento nos demos cuenta de que otras características de la clase no coinciden con las características del objeto, con lo cual la hipótesis abductiva queda descartada. Como vemos, este proceso esta íntimamente vinculado con el mecanismo de la analogía.<br />Conclusión<br />En el diseño orientado a objeto la herencia es la cantidad de jerarquías de clases desarrolladas dentro de un rango de niveles de especialización por jerarquía de clases desarrolladas en un porcentaje de jerarquías sobre clases desplegadas con rango de porcentaje de métodos reemplazados en una jerarquía, la cantidad de clases raíz no abstractas o cantidad de clases raíz no abstractas que implementan Interface. <br />El diseño es necesariamente un proceso de simplificación, de reducción. Como bien comenta Borges en Funes, el memorioso, pensar (¿diseñar? ¿Modelar? ¿Hacer ciencia?) Es olvidar diferencias, generalizar, abstraer cualquier intento de conocer la realidad está obligado a operar de manera inevitable una drástica reducción de su infinita complejidad mediante una operación que, de manera básica, consiste en proponer cuáles serán los elementos o componentes relevantes que se tomarán en cuenta y qué aspectos de ello serán atendidos a la hora<br />