Programacion Orientada A Objetos

ORIENTACIN A OBJETOS: CONCEPTOS, TERMINOLOGA Y LENGUAJES (PARTE 1)
Versin 3.0 (2012) Miguel ngel Abin
El cuadro La traicin de las imgenes, del pintor surrealista belga Ren Magritte, se reproduce con carcter ilustrativo y pedaggico. No se persigue ningn nimo de lucro.
Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

Resumen: Este tutorial, dividido en dos partes, proporciona una introduccin a la terminologa y los conceptos de la orientacin a objetos (OO), as como a los lenguajes orientados a objetos. Esta primera parte presenta los trminos y conceptos de la OO desde un punto de vista conceptual, dando definiciones intuitivas y manejables, e introduce el anlisis y diseo OO. Hay tambin una comparacin con la metodologa estructurada. En la segunda parte (http://www.javahispano.org/portada/2011/8/1/orientacion-aobjetos-ii.html), se explican ampliamente conceptos como clase, objeto, mensaje, tipo abstracto de datos, polimorfismo y relacin. Adems, se explican las principales caractersticas de los lenguajes OO ms populares, se muestra cdigo que implementa los conceptos de la OO (polimorfismo, herencia, etc.) en diversos lenguajes OO (Java, C++...) y se estudia la evolucin de los lenguajes OO. Abstract: This tutorial, divided in two parts, provides an introduction to Object-Oriented (OO) terminology and concepts, and to Object-Oriented languages. This first part introduces OO terms and core concepts from a conceptual point of view, giving intuitive and manageable definitions, and introduces OO analysis and design (OOAD). There is also a comparison with the structured methodology. In the second part (http://www.javahispano.org/portada/2011/8/1/orientacion-aobjetos-ii.html), concepts like class, object, message, Abstract Data Types, polymorphism, inheritance and relationship are widely explained. In addition, the main caracteristics of the more popular OO languages are explained, code implementing the OO concepts (polymorphism, interitance) is shown for several Object-Oriented languages (Java, C++), and the evolution of OO languages is analysed.
Keywords: Abstraction, Classes, CRC Cards, Encapsulation, Hierarchy, Object Orientation, Modularity, Objects, Object Orientation, Object Oriented OOAD, Object Oriented Design, Object Oriented Methodology, Object Paradigm, Object Oriented Programming, Object Oriented Terminology, Analysis, Software Design, Structured Methodology
Learning Analysis, Oriented Software
Miguel ngel Abin, 2002-2012
Pgina 2 de 55
http://www.javahispano.org
NDICE
1. Introduccin. El porqu de este trabajo 2. Glosario de la orientacin a objetos 3. Visin general de la orientacin a objetos 3.1 Orgenes de los conceptos de la OO 3.2 La orientacin a objetos como metodologa de desarrollo de sistemas. 3.2.1 Introduccin 3.2.2 El anlisis OO. Casos de uso 3.2.3 El diseo OO 3.2.4 La programacin OO 3.3 Comparacin de la OO con la metodologa estructurada 4. Fundamentos de la orientacin a objetos 4.1 Abstraccin 4.2 Modularidad 4.3 Encapsulacin 4.4 Jerarqua 5. Lenguajes de programacin orientados a objetos. Puede utilizarse la OO en lenguajes no orientados a objetos? 6. El paradigma orientado a objetos: xitos y fronteras 6.1 l xito del paradigma orientado a objetos, se basa nicamente en criterios objetivos? 6.2 Los lmites de la POO Sobre el autor Pgina 5 Pgina 10 Pgina 18 Pgina 18 Pgina 18 Pgina 18 Pgina 20 Pgina 28 Pgina 34 Pgina 35 Pgina 41 Pgina 41 Pgina 42 Pgina 43 Pgina 45 Pgina 47 Pgina 52 Pgina 52 Pgina 54 Pgina 55
Pgina 3 de 55

Miguel ngel Abin
Fecha de creacin: 23.04.2012 Versin: 3.0
Copyright (c) 2002-2012, Miguel ngel Abin. Este documento puede ser distribuido slo bajo los trminos y condiciones de la licencia de Documentacin de javaHispano v1.0 o posterior (la ltima versin se encuentra en http://www.javahispano.org/licencias/).
Abandonadlo todo. Abandonad a Dad. Abandonad a vuestra mujer, abandonad a vuestra amante. Abandonad vuestras esperanzas y vuestros temores. Abandonad a vuestros hijos en medio del bosque. Soltad al pjaro en mano por aquellos que estn volando. Abandonad si hace falta una vida cmoda, aquello que os presentan como una situacin con porvenir. Lanzaos a los caminos. Andr Breton, Les Pas perdus (1924) Yo invent el trmino orientacin a objetos, y puedo decirle que no estaba pensando en C++. Frase atribuida a Alan Kay, creador del primer lenguaje OO puro, en la OOPSLA 97 Solamente hay dos cosas equivocadas en C++: el concepto inicial y la implementacin. Bertran Meyer, creador de Eiffel La programacin orientada a objetos es, en cierto sentido, slo un truco de programacin que usa indireccin. Es un truco que los buenos programadores llevan aos usando. Bjarne Stroustrup, creador de C++ Los objetos en el sentido de la orientacin a objetos han estado presentes entre nosotros desde que se desarroll la conciencia en la especie humana, pero se ha tardado miles de aos en aprovecharlos como tcnica. Cunto tiempo ms se necesitar para extraer el mximo rendimiento de la OO? [...] Quiz necesitemos un cambio conceptual antes que una sucesin frentica de cambios tcnicos. Howard Humphrey (2002) Convertir C en un lenguaje orientado a objetos es como tratar de convertir un perro en un pulpo clavndole ms piernas. Steve Taylor
Pgina 4 de 55
C te trata como un adulto consentido. Pascal te trata como un chico desobediente. Ada te trata como un criminal. Bruce Powel Douglass Ah, Java. Todo el rendimiento de Smalltalk combinado con la claridad sintctica de C++. Annimo Conocer la sintaxis de Java no convierte a nadie en un ingeniero de software. John Knight Cualquier programador lo suficientemente persistente y empecinado conseguir escribir cdigo al estilo Fortran o Cobol en cualquier lenguaje de programacin que utilice. Annimo. Odo en la Universidad de Valencia
1. Introduccin. El porqu de este trabajo

El propsito de este trabajo, presentado en dos partes, consiste en realizar una introduccin a la orientacin a objetos (OO); introduccin que incluye sus conceptos, su terminologa y un repaso de los lenguajes OO ms conocidos y de la evolucin de stos. No pretendo slo definir formalmente los conceptos de la OO, sino tambin presentarlos de una forma inteligible e intuitiva, pero no carente de precisin. Para conseguirlo no he escatimado en ejemplos ni en figuras. Con este trabajo adquirir una base para manejarse por las tecnologas y las metodologas OO, que dominan actualmente la ingeniera del software. La primera versin de este trabajo gan un concurso que se celebr por el tercer aniversario de javaHispano (2004). Los lectores de javaHispano lo votaron como el mejor tutorial publicado en el portal. Por no saber, yo ni saba que exista el concurso hasta que Alberto Molpeceres me comunic que haba ganado en la categora de Mejor tutorial. Por cierto, como premio eleg dos libros relacionados con la OO. Para esta nueva versin, mi mayor recompensa consistira en hacerle sentir curiosidad por la OO o en mostrarle algn aspecto de la OO que se le haya pasado por alto.
En esta primera parte del trabajo expongo de manera introductoria el anlisis y diseo (general y OO), comparo la OO con la metodologa estructurada, explico los fundamentos de la OO y analizo los motivos de su xito (no siempre de carcter meramente tcnico). En la segunda parte (http://www.javahispano.org/portada/2011/8/1/orientacion-aobjetos-ii.html) presento en detalle, y en ocasiones formalmente, los conceptos de la OO: clases, objetos, mensajes, polimorfismo, herencia, tipos abstractos de datos, etc. Adems, expongo la evolucin de los lenguajes orientados a objetos y explico cmo se materializan esos conceptos en cada lenguaje, enumerando las diferencias y similitudes entre ellos. Para algunos lenguajes (Java, C++, Smalltalk, Eiffel) incluyo cdigo fuente. Dado que el trabajo se publica en javaHispano, la mayora de los ejemplos estn escritos en Java. En un futuro cercano, tambin publicar una versin 2.0 de la segunda parte.
Pgina 5 de 55
Deliberadamente, esta primera parte de Orientacin a objetos: conceptos, terminologa y lenguajes se centra en los conceptos y definiciones de la OO, y no en su aplicacin a lenguajes de programacin concretos. stas son mis razones para hacerlo as: El anlisis y diseo orientado a objetos no tiene por qu vincularse necesariamente a sistemas de software. En los sistemas de software, la orientacin a objetos no se restringe a lenguajes de programacin concretos, aun cuando se presenten como lenguajes OO. La OO es una metodologa general de desarrollo de software, independiente del lenguaje utilizado, si bien hay lenguajes que cuentan con mejores mecanismos que otros para poder aplicarla eficazmente. Utilizar la OO es ms que programar en uno o varios lenguajes de programacin: implica manejarla como metodologa de desarrollo. Si una aplicacin no incluye abstraccin, encapsulacin, jerarquas, mensajes y polimorfismo no est orientada a objetos, aunque est escrita en Java, C++ u otro lenguaje OO. A lo largo de diecisis aos he visto, en programas de compaeros y clientes, clases con miles de lneas y decenas de mtodos estticos, clases compuestas slo por mtodos, clases con cohesin tan fuerte que volvan el cdigo irreutilizable, usos de la herencia que derivaban en cdigo confuso e inestable... Me consta que no son hechos aislados: cualquier programador o analista con cierta experiencia puede referir hechos similares, si no calcados. El motivo de estos y tantos otros errores suele ser simple. A saber: el programador ha pasado de un lenguaje estructurado a uno orientado a objetos sin tener claros o haber madurado los conceptos de la OO. Aparentemente, los conceptos de la OO son muy sencillos..., pero ya se sabe: el diablo est en los pequeos detalles. En los lenguajes OO puede proseguirse, consciente o inconscientemente, con un enfoque estructurado de programacin, al igual que puede escribirse con una pluma de ave y tinta china, pero resulta inadecuado. Este ltimo motivo es ms prosaico: en la segunda parte del tutorial se explica cmo se traducen a los lenguajes OO los conceptos explicados en esta primera parte.
S que existe una gran diferencia entre comprender los fundamentos de la orientacin a objetos y aplicarlos con xito: entre teora y prctica siempre hay una gruesa zanja. Por eso, aunque lea estas pginas con atencin, necesitar prctica, paciencia y esfuerzo para escribir buenos programas OO. Debera, pues, prescindir de los conceptos e ideas de la OO, y buscar un libro sobre la sintaxis de Java o empezar a escribir cdigo teniendo delante algn manual de ayuda? No. Tal como dice una de las frases que abren este trabajo: Conocer la sintaxis de Java no convierte a nadie en un ingeniero de software. Lo crea o no, hay ms sabidura en la frase que en algunos libros de programacin. Aparte, los lenguajes van y vienen, pero los conceptos suelen mutar poco. Es mucho ms til conocer para qu sirve la herencia, sus tipos (mltiple, de generalizacin, de implementacin, de especializacin...) y cundo usarla y cundo no
Miguel ngel Abin, 2002-2012 Pgina 6 de 55
que saber que Java implementa la herencia (de qu tipo?) mediante la palabra clave extends. Conocer los conceptos de la OO le ayudar a saber qu puede hacer en cada lenguaje OO y cmo hacerlo, sin atarse obligatoriamente a ninguno en concreto.
En el campo de la orientacin a objetos, las tecnologas han intentado suplantar a las ideas; pero eso slo ha producido confusin entre los desarrolladores y, al final, ha dificultado que se usar una OO estndar. Qu sentido tiene la encapsulacin en un lenguaje OO donde los punteros permiten acceder a las variables privadas? Es conveniente que ms de cien metodologas OO vaguen por ah, como vampiros hambrientos de sangre del cliente? Por qu se permite, en un lenguaje OO, la mezcla de clases y de estructuras de datos no OO? Hace algunos aos, vi un anuncio televisivo sobre una herramienta que ha fragmentado un poco ms la OO. En l sala un actor, disfrazado de Elvis Presley, que haca de programador. Pasaba unos segundos tecleando en el ordenador, y enseguida coga su guitarra y entonaba una cancin de Elvis. El mensaje del anuncio no precisa muchas alforjas: con la herramienta se acaba enseguida el trabajo y uno puede dedicarse a lo que le gusta, aunque sea desafinar como una nutria en celo. Bien, Johnny Carson dijo: Si la vida fuera justa, Elvis estara vivo; y sus imitadores, muertos. No s si la vida fue justa con Elvis o no; pero estoy seguro de que no lo ha sido con la orientacin a objetos. La pobre ha tenido y tiene ms metodlogos de los que necesitaba; y muchos lenguajes y herramientas le han hecho un flaco favor. Suscribo por completo las palabras de Wolfgang Strigel cuando escribe Los conceptos bsicos de la OO se conocen desde hace dos dcadas, pero su aceptacin todava no est tan extendida como los beneficios que esta tecnologa puede sugerir y La mayora de los usuarios de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se pretenda. Esta prctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en diversos grados (la negrita es ma).
Antes de proseguir, debera saber qu es para m la programacin orientada a objetos (POO). Desde mi punto de vista, la POO es una herramienta para reducir la complejidad de los sistemas de software. Usando la orientacin a objetos, un sistema que ocupa miles o millones de lneas de cdigo puede organizarse como una coleccin de pequeas unidades (objetos), cada una con cierta independencia y ciertas responsabilidades. Un programa OO consiste en un conjunto de objetos que intercambian mensajes; cada objeto decide por s mismo si debe o no aceptar los mensajes que recibe, as como la interpretacin de cada mensaje. En un programa OO medianamente complicado, los objetos no son totalmente independientes: unos heredan propiedades y funciones de otros; algunos necesitan consultar a otros para desempear sus tareas; otros llevan dentro de s ms objetos... La principal ventaja que percibo en la POO estriba en que un programa de objetos se extiende y mantiene de manera ms sencilla que uno sin ellos. Si el programador necesita objetos que las empresas de software no fabrican o comercializan, puede construir sus propios objetos tomando un objeto ya existente y personalizndolo conforme a sus necesidades. De la misma manera, si un programa OO no funciona como se desea, encontrar el fallo resulta ms sencillo que en uno estructurado o funcional: el error estar muy localizado; es decir, se encontrar en la pequea porcin de cdigo de un objeto, y no repartido entre decenas o cientos de lneas.
La POO se apoya firmemente en el anlisis y diseo OO. Considero que escribir un programa OO sin hacer antes el anlisis y diseo OO se parece a construir un mueble sin haber analizado para qu servir y cules sern las dimensiones de sus componentes. Al final se tendr un mueble, pues la persistencia humana carece de lmites y, a menudo, de sensatez; pero las puertas no cerrarn bien, costar abrir los cajones, el mueble se tambalear con cualquier golpe... En fin, si uno no sabe adnde quiere ir, cualquier lugar le vale. Por el inters que merece el anlisis y diseo OO, le dedico un cierto espacio en ambas partes del tutorial. En la primera, uso una perspectiva general e intuitiva; en la segunda, vistos ya todos los conceptos de la OO, profundizo un poco ms (desgloso una serie de pasos para el diseo OO y expongo los principios generales de diseo OO).
El lector crtico se preguntar si la OO no es ya algo pasado, superado por nuevos enfoques y tcnicas. No: la OO sigue siendo la metodologa universalmente aceptada para construir grandes sistema de software. Los conceptos de la OO siguen presentes en proyectos tan actuales y ambiciosos como la Web semntica: una red, prolongacin de la actual, que contendr informacin comprensible para las mquinas, de modo que las aplicaciones podrn sacar conclusiones de los datos (razonamiento automtico) y realizar para nosotros tareas impensables hoy da (negociacin automtica entre empresas, bsquedas que tengan en cuenta el contexto de las palabras, integracin de informacin procedente de fuentes arbitrarias). La Web semntica codificar los recursos de la Web mediante objetos, clases y relaciones entre ellas (dicho en forma tcnica, mediante ontologas). Si desea saber ms sobre la Web semntica y sobre cmo utiliza los conceptos de la OO, puede consultar El futuro de la Web (http://www.javahispano.org/portada/2011/8/1/el-futuro-de-la-web.html).
Ha mejorado el mundo gracias a la OO? Observo con tristeza que el mundo se encamina rpidamente hacia una sociedad del 20%-80%. Es decir, una sociedad donde el 20% de las personas se dedicar a trabajos estables, bien remunerados y socialmente reconocidos, relacionados con la gestin, la economa y las tecnologas de la informacin; y donde el otro 80% se dedicar a tareas poco especializadas, mal remuneradas y carentes de estabilidad laboral o de seguridad social. Especialmente cnica me resulta la actitud de algunas instituciones internacionales que siempre recomiendan recortar o suprimir el gasto pblico en seguridad social, educacin y pensiones; cuando sus trabajadores gozan de pensiones vitalicias, buenos sueldos y seguros mdicos privados para ellos y sus familias. Lo mismo puedo decir de cierta superpotencia que se dedica a preservar como sea los derechos de autor y las patentes de sus ciudadanos, olvidando convenientemente que cuando era una nacin en desarrollo (hasta bien entrado el siglo XIX) no respetaba los derechos intelectuales de los autores extranjeros. Puesto a tirar balones hacia dentro, tambin me parecen sumamente reprochables las medidas de liberalizacin que cierta comunidad de pases occidentales exige ya a los pases subdesarrollados o en vas de desarrollo, cuando esa comunidad tard 50 aos en adoptar esas medidas. La medicina que el mdico receta a los dems no es la que l toma, desde luego. Por eso ha llegado a ser mdico. Ha contribuido la OO a que se cree la sociedad del 20%-80%? Por una parte, como la OO ha acelerado y abaratado la construccin de grandes sistemas de software, imprescindibles para las tecnologas de la informacin, ha contribuido y contribuye a formar esa sociedad. Por otra, el hincapi de la OO en la reutilizacin del cdigo y su asociacin con entornos visuales de programacin y metodologas iterativas han
favorecido que los lenguajes orientados a objetos hayan salido fuera del crculo de los iniciados; y han permitido que se generen muchas herramientas libres y de cdigo abierto (algunas de calidad desigual);. Estas herramientas estn siendo usadas gratuitamente por desarrolladores que no podran pagar, aunque quisieran, herramientas de pago. Ahora que le he mostrado la cara y la cruz de la OO, le toca a usted quedarse con la que prefiera.
En esta tercera versin de la parte 1 de Orientacin a objetos he revisado y aumentado el material que haba en la primera versin. Sigo escribiendo en javaHispano sobre la OO por varios motivos: primero, sigo reflexionando sobre ella; segundo, contino leyendo libros y artculos que tratan esta materia; tercero, sigo probando lenguajes y herramientas OO. Mientras escriba esta introduccin, tena sobre la mesa unas frases de Richard P. Feynman que pronunci una vez en una charla sobre electrodinmica clsica. Los rostros de los asistentes hace tiempo que se esfumaron de mi memoria, pero an conservo el folio donde anot las frases (no recuerdo ya de dnde las saqu):
Nunca ms volver a cometer el error de leer opiniones de expertos. Pero, evidentemente, uno solamente tiene una vida. Comete en ella todos los errores y aprende qu cosas no debe hacer. Y cuando lo sabes, es que has llegado al final.
Tanto en la OO como en tantas otras cosas, sigo cometiendo errores y, lo que es mucho peor, sigo leyendo opiniones de expertos. Cuanto ms s sobre la OO, ms dudas tengo y ms escurridizos me parecen sus conceptos y tcnicas. Cuanto ms intento atrapar las ideas de la OO y fijarlas en el papel, ms intangibles se vuelven. Cuanto ms hablo con expertos en modelado OO, ms sutileza y artesana veo en su trabajo. Con todo, creo que esta tercera versin del trabajo resulta ms exacta y completa que las dos anteriores y aclara algunas ambigedades.
Pgina 9 de 55
2. Glosario de la orientacin a objetos

En esta seccin se definen unos cuantos conceptos que aparecern en el trabajo. Resulta necesario contar con un glosario sobre la OO; tanto ms cuanto que existen muchos lenguajes de programacin OO, muchas metodologas, y muchos autores que usan los mismos trminos para referirse a distintos conceptos. Con el glosario, evitaremos confusiones y ambigedades. En la definicin de cada entrada marco en azul las palabras que, a su vez, son otras entradas del glosario (slo la primera vez que aparecen). Algunas definiciones como clase, objeto, mensaje y operacin son provisionales y se concretan ms en la segunda parte de Orientacin a objetos: conceptos, terminologa y lenguajes de programacin (http://www.javahispano.org/portada/2011/8/1/orientacion-a-objetos-ii.html). Anlisis: Proceso que genera el modelo conceptual de un dominio de inters. Cuando se desea construir un sistema (sea de software o no) para un dominio, el anlisis tambin captura los requisitos que el sistema debe cumplir. Clase (de objetos): En un modelo de dominio, define un conjunto de propiedades compartido por un determinado grupo de entidades (cosas materiales, conceptos, ideas, sucesos); es una abstraccin de los objetos similares de un dominio. Por ejemplo, una clase Compra representa el conjunto de las transacciones comerciales que son compras, y tiene propiedades o atributos como fecha y hora. En la programacin orientada a objetos (POO), una clase es un fragmento de cdigo que describe los atributos y operaciones de los objetos (instancias) que pueden generarse a partir de ella. Por ejemplo, en una clase Cliente, los atributos podran ser nombre y direccin, y las operaciones podran ser aadir(), borrar() y actualizar(). Las clases puede entenderse como plantillas para fabricar objetos. Diseo: Proceso que usa los resultados del anlisis para generar una especificacin de la implementacin de un sistema o producto. Los diseos suelen usar dibujos, iconos, modelos o planos. A menudo, la palabra diseo se utiliza tambin para referirse a la descripcin lgica del funcionamiento del sistema o producto. Dominio: Parte del mundo real bajo estudio. Cuando consideramos sistemas de software, el dominio es el campo o mbito para el cual se construye el sistema. Por ejemplo, una aplicacin de contabilidad cae dentro del dominio financiero. Ingeniera del software: Disciplina cuyo propsito es la produccin de software libre de fallos, dentro del plazo previsto, cumpliendo el presupuesto inicial, y que satisfaga las necesidades del usuario o cliente. Ingeniero/a de software: Persona que aplica las tcnicas de la ingeniera del software y que a menudo tiene que afrontar con tranquilidad de espritu, mirada resignada y autocontrol Zen las reducciones de los plazos de entrega, los recortes en el presupuesto original y las modificaciones sustanciales y sin previo aviso de los requisitos iniciales.
Pgina 10 de 55
Instancia: Materializacin de un objeto durante el tiempo de ejecucin de un programa. En trminos computacionales, una instancia corresponde directamente a un bloque contiguo de memoria, que comienza en una direccin de memoria y ocupa cierto espacio. Las instancias de una misma clase se diferencian entre s porque cada una tiene su propio bloque de memoria. Por lo general, los trminos instancia (de una clase) y objeto se usan indistintamente. Mensaje: Estmulo enviado a un objeto con un nombre y unos argumentos adecuados, que provoca que el objeto comience cierto comportamiento al activarse la operacin asociada al mensaje. Los mensajes modifican el estado del objeto o devuelven informacin sobre su estado. Por ejemplo, un mensaje devolverAltura enviado a un objeto Persona devuelve la altura del objeto. Metodologa: Coleccin de tcnicas repetibles para resolver una familia de problemas. Por ejemplo, un libro de bricolaje contiene una metodologa para hacer, en la propia vivienda, obras de carpintera, fontanera y electricidad. En software, el anlisis y el diseo suelen realizarse siguiendo una determinada metodologa. Tradicionalmente, en francs, ingls y espaol siempre haba existido la diferencia entre metodologa (conjunto de mtodos que se siguen en una investigacin cientfica o en una exposicin doctrinal) y paradigma (modelo, patrn). Actualmente, en informtica se ha perdido esa diferencia: los ingenieros de software usan paradigma y metodologa en el sentido de coleccin de tcnicas para resolver problemas. En este trabajo mantendr la diferencia entre ambos trminos. Metodologa de desarrollo de sistemas: Metodologa para producir sistemas de forma organizada, empleando una coleccin predefinida de tcnicas y convenciones de notacin. En el caso de los sistemas de software se usan metodologas de desarrollo de software (tambin llamadas metodologas de ingeniera del software). Modelo: Esquema terico de un sistema o de una realidad compleja, que se elabora para facilitar su comprensin y el estudio de su comportamiento. Un modelo suele representarse mediante diagramas ms los textos, notaciones o aclaraciones necesarias para entenderlos. Por ejemplo, en arquitectura, el plano de un edificio es un modelo. Modelo de dominio o conceptual: Representacin de los conceptos presentes en un dominio de inters. Por ejemplo, en un dominio empresarial, el modelo de dominio incluye conceptos como compra, venta, gestin de almacenes, etc., as como las relaciones entre ellos. El modelo de dominio suele incluir aclaraciones y explicaciones sobre los conceptos. En ocasiones comprende un glosario. Modelo de software: Representacin de un componente de software (una clase o un mdulo, por ejemplo) o un sistema de software. Los modelos de software suelen representarse en UML. Objeto: En un modelo de dominio, abstraccin de alguna entidad presente en el dominio de inters. Los objetos y las clases se hallan muy relacionados: una clase abstrae el conjunto de propiedades que comparte un grupo de cosas tangibles, conceptos, ideas o sucesos. Preguntarse
qu viene antes, si el objeto o la clase, es similar a preguntarse qu fue antes, si el huevo o la gallina. En la POO, estructura de datos encapsulada con un conjunto de operaciones que operan sobre los datos. Todo objeto tiene identidad propia, comportamiento (conjunto de operaciones) y estado (definido por los valores de sus atributos o propiedades y por sus relaciones con otros objetos). Para activar una operacin de un objeto, basta enviarle un mensaje. Operacin: Descripcin de la habilidad de un objeto para responder a un mensaje, as como de los requisitos de ste. La implementacin de una operacin para una clase (es decir, el cdigo que define la accin asociada al mensaje) se denomina mtodo o funcin. Las operaciones vlidas para un objeto se definen en la clase de la que procede. Orientacin a objetos (OO): Metodologa para desarrollar sistemas mediante clases y objetos. En el campo del software, la OO es una metodologa de ingeniera del software que se basa en estos fundamentos: abstraccin (clases), encapsulacin (clases), modularidad (clases) y jerarqua (herencia y polimorfismo). Paradigma: Estrategia o punto de vista para realizar tareas o resolver problemas. Marco conceptual. Programacin orientada a objetos (POO): Metodologa de programacin basada en objetos y en el envo de mensajes entre stos. Los fundamentos de la POO son los de la OO. Relacin o asociacin: Abstraccin de un conjunto de interrelaciones semnticas concretas que se dan sistemticamente entre distintos tipos de objetos. Por ejemplo, si se abstrae el hecho de que todos los automviles tienen ruedas, se obtiene una relacin lleva entre las clases Automvil y Rueda. Las relaciones o asociaciones describen un conjunto de posibles interrelaciones, del mismo modo que las clases describen un conjunto de posibles objetos. Requisito: Descripcin de lo que debe hacer un sistema o producto (requisito funcional) o de cmo debe implementarse (requisito no funcional o tcnico). Verbigracia, en un sistema de software empresarial, un requisito podra ser ste: Las compras que excedan los 1.000 se guardarn en la base de datos de mejores clientes. Sistema: Grupo de elementos, componentes o dispositivos que se integran para conseguir ciertos propsitos o funciones. Por ejemplo, un sistema informtico se compone de hardware y software. UML: Lenguaje grfico que se usa principalmente para visualizar, especificar, construir y documentar componentes de software (una clase de Java, por ejemplo) y sistemas de software (una aplicacin de gestin empresarial, p. ej.). Aunque UML se ha convertido en el lenguaje estndar para los modelos de software OO, es un lenguaje de modelado de propsito general: puede usarse para modelar sistemas que no son de OO ni de software (por ejemplo, empresas).
Pgina 12 de 55
Mundo real Cosa Concepto, idea, abstraccin Interaccin
Orientacin a objetos Objeto Clase Operacin
Tabla 1. Equivalencias entre algunos conceptos del mundo real y de la orientacin a objetos.
arranca hojas anota enciende apaga
Luis Domingo
Miguel ngel Abin, enero 2006
Figura 1. Ejemplo de modelo de dominio o conceptual. Los conceptos y las relaciones se han extrado de un sencillo anlisis del dominio de una oficina. En el caso de que los trminos del dominio sean poco habituales, el modelo conceptual suele incluir un glosario con los trminos que aparecen en el dominio.
Pgina 13 de 55
arranca hojas 1 anota Empleado

Nombre Apellidos
Agenda
Precio
Ordenador enciende apaga 1

Fabricante Velocidad Memoria
Figura 2. Ejemplo de modelo conceptual (o de dominio) orientado a objetos. Los conceptos que aparecen en la figura 1 se han convertido en clases. Este modelo conceptual OO es una representacin un poco ms formal del mostrado en la figura 1. Ninguno de los dos tiene nada que ver con el software. El nmero 1 hace referencia a la multiplicidad: un empleado arranca hojas de una agenda (la suya), anota en una agenda, enciende y apaga un ordenador (el suyo). Del mismo modo, las hojas de una agenda son arrancadas por un empleado, slo un empleado escribe en ellas, y un ordenador es encendido y apagado por un empleado.
Pgina 14 de 55
Agenda 1 Empleado
nombre: String apellidos: String fichar(fecha: Date) trabajar() tomarCafe() precio: double anotar(texto: String) arrancarHoja()
Ordenador 1
fabricante: String velocidad: int memoria: int encender() apagar()
Figura 3. Modelo de software correspondiente al dominio de la figura 2 (he aadido algunos mtodos para Empleado). Establece cmo deben ser las clases de software, sin especificar en qu lenguaje (Java, C++, etc.) van a ser implementadas. Este modelo, orientado a objetos, contiene tres clases de software, cada una con sus atributos y operaciones. El modelo de software recuerda al modelo conceptual o de dominio, pues los conceptos del mundo real se transforman en clases del modelo de software. Ahora bien, el modelo de software no es una representacin exacta del mundo real. En las figuras 1 y 2, por ejemplo, era el empleado quien encenda el ordenador; en la figura 3, el ordenador dispone de una operacin encender().
Pgina 15 de 55
<<object>> joseLuis: Empleado <<class>> Empleado

nombre: String apellidos: String fichar(fecha: Date) trabajar() tomarCafe() <<instanceOf>> <<instanceOf>> nombre: Jos Luis apellidos: Ferreira
<<object>>
<<instanceOf>>
mperez: Empleado
nombre: Manolo apellidos: Prez
<<object>> cpidd: Empleado

nombre: Colin apellidos: Piddington
Figura 4. Modelo de software de una clase y tres instancias suyas. Utilizo los estereotipos de UML. La clase acta como plantilla de instancias u objetos. Cada objeto posee identidad (cada uno tiene su propia direccin de memoria), estado (valores de los atributos o propiedades + relaciones con otros objetos) y comportamiento (todo lo que puede hacer).
Pgina 16 de 55
Figura 5. Este modelo describe una interfaz MIDI para un ordenador Apple Macintosh. Cada smbolo tiene un significado preciso, que puede encontrarse en cualquier manual de electrnica. Los modelos de sistemas de software no difieren mucho de los modelos de sistemas elctricos o electrnicos. En un mundo ideal, los sistemas de software se disearan ensamblando componentes prefabricados, tal como se hace con los circuitos electrnicos.
Pgina 17 de 55
3. Visin general de la orientacin a objetos

3.1 Orgenes de los conceptos de la OO
Pese a que el trmino orientacin a objetos ejerce una innegable fascinacin para muchos ingenieros de software recin salidos de la universidad, gran parte de sus conceptos distan mucho de ser nuevos. Algunos, incluso, forman parte de la tradicin cultural de Occidente: Platn y Aristteles usaron en sus escritos trminos como objetos, clases, subclases, clasificaciones, etc. (Posiblemente, Aristteles llev demasiado lejos el concepto de clase: clasific dentro del mismo grupo a la cotorra y la lechuga, pues ambas son verdes) Ya a principios del siglo XX, Alfred North Whitehead (1861-1947) y Bertrand Russell (1872-1970) formalizaron y ampliaron los anteriores conceptos, tratando de proporcionar infructuosamente una base lgica autoconsistente para la matemtica. Las definiciones lgicas y filosficas de esos conceptos han influido mucho en la terminologa OO. Por ejemplo, en los Principia Mathematica [Bertrand Russel & Alfred N. Whitehead, 1910] se define clase como una coleccin de objetos a los que se aplica un concepto, y esta misma definicin fue la que inspir el trmino clase en la OO e influy en el desarrollo de los lenguajes de programacin SIMULA I (1962-65) y Simula 67 (1967). Ambos lenguajes, desarrollados en el Centro Noruego de Computacin (Oslo) por Christian Nygaard y Ole-Johan Dahl, son considerados los primeros lenguajes OO; su influencia conceptual subyace en todos los actuales lenguajes OO. Lo anterior no tiene un inters nicamente anecdtico o histrico: los conceptos matemticos, lgicos y filosficos permiten expresar con exactitud y sin ambigedades lo que hoy se considera orientacin a objetos. Adems, la OO (y, por tanto, el software OO) evolucionar con el tiempo hacia caminos an inciertos, y son los conceptos lgicomatemticos y filosficos los que seguirn usndose para elaborar lo que denomino orientacin a objetos no estndar e incluso para elaborar nuevos mtodos de anlisis y diseo, de lejano parentesco con la OO. Si existe algo parecido a la inmortalidad, los conceptos matemticos lo tienen: las ideas de Pitgoras pervivirn ms que las obras de Cervantes, y seguirn vigentes cuando usted y yo seamos cenizas alrededor de un sol moribundo.
3.2 La orientacin a objetos como metodologa de desarrollo de sistemas.

3.2.1 Introduccin Aunque todava suele asociarse la orientacin a objetos a determinados lenguajes de programacin (Java, C++, Smalltalk, etc.), es mayoritaria la opinin de que la OO es una metodologa de desarrollo de sistemas (informticos o no). La orientacin a objetos puede aplicarse a la ingeniera de procesos, a la gestin empresarial, etc. La orientacin a objetos considera los sistemas como colecciones de objetos capaces de interactuar, que trabajan conjuntamente para realizar tareas. Como toda metodologa, incluye actividades de anlisis y diseo. En el caso de los sistemas de software, comprende tambin actividades de programacin. En los siguientes subapartados veremos en qu consisten dichas actividades. Dentro del marco general de la OO, hay muchas metodologas OO (en rigor, deberan llamarse submetodologas, pero ningn metodlogo que se precie usara el
prefijo sub para su creacin). Cada metodologa OO detalla con precisin las tcnicas que deben usarse en cada actividad y emplea una o ms notaciones, generalmente grficas, para describir los modelos que se van generando.
LA METODOLOGA OO AL COMPLETO
Anlisis OO Diseo OO Avion
- modelo: String - codigo: String aterrizar() despegar()
Programacin OO
public class Avion{ private String modelo; private String codigo;
public void aterrizar{...} public void despegar{...} }
Figura 6. Las tres etapas de la OO (aplicada a sistemas de software).
Pgina 19 de 55
3.2.2 El anlisis OO. Casos de uso El anlisis descubre y modela los aspectos relevantes de un dominio donde hay algn problema que interesa resolver; a este dominio se le llama dominio del problema o de inters. Por ejemplo, en el dominio de la fsica de altas energas, el problema consiste en averiguar cmo interaccionan las partculas elementales; en el dominio de una empresa, el problema podra consistir en gestionar la contabilidad. En general, el anlisis parte de una definicin del problema, casi siempre imprecisa y ambigua, y genera dos cosas: a) una descripcin precisa y exacta del problema; b) un modelo preciso, conciso, comprensible y exacto del dominio del problema. En el campo de la ingeniera, el problema suele consistir en crear un sistema (elctrico, mecnico, informtico, arquitectnico, etc.) que satisfaga las necesidades de clientes y usuarios: gestionar un almacn, levantar un muro, evitar las sobrecargas de tensin, mejorar la eficacia de un motor... No resulta infrecuente que el problema consista en sustituir un sistema ya existente por otro mejor. En ambos casos, el dominio del problema coincide con la parte del mundo real para la cual se desarrolla el sistema (un departamento, una empresa...). Dentro del anlisis, el anlisis de requisitos se encarga de descubrir los requisitos que el sistema debe cumplir: La aplicacin permitir registrar los envos que lleguen, El muro deber tener una seccin mxima de 0,5 metros cuadrados, El circuito impedir el paso de cualquier corriente con ms de 100 miliamperios, El motor no disipar ms del 40% de la energa que recibe... Por medio del anlisis de requisitos, el analista descubre y formula precisamente los requisitos que debe cumplir un sistema para satisfacer las necesidades de clientes y usuarios. Partiendo de la descripcin del problema proporcionada por stos, obtiene una lista de requisitos para el sistema. Los requisitos no corresponden a una propuesta de solucin: reflejan lo que el sistema debe hacer, pero no cmo debe hacerlo. El anlisis de requisitos se revela crucial para establecer lo que realmente se pide al sistema: las descripciones de clientes y usuarios suelen ser incompletas, ambiguas e incluso inconsistentes. Al lector interesado en saber ms sobre el anlisis de requisitos le recomiendo Requirements Engineering [Ian Sommerville & Pete Sawyer, 1997]. Una vez se han obtenido los requisitos del sistema, el analista los usa (junto con su conocimiento del mundo real y sus entrevistas con especialistas en el dominio) para fabricar un modelo conceptual del dominio del problema, es decir, una representacin de los conceptos ms relevantes del dominio para el que se desarrolla el sistema. A partir de la descripcin del problema (requisitos), del conocimiento de los expertos en el dominio y del conocimiento general sobre el mundo real, el anlisis OO describe el dominio del problema mediante clases y objetos. En otras palabras, construye un modelo de dominio orientado a objetos. En la figura 2 se muestra un modelo de dominio OO; en la figura 1 hay un modelo de dominio no orientado a objetos. El anlisis de requisitos y el OO estn fuertemente vinculados (vase la figura 7): el primero describe el sistema deseado (el problema) mediante una lista de requisitos; el segundo usa los requisitos, junto con el conocimiento mencionado en el prrafo anterior, para generar un modelo de dominio OO, correspondiente al dominio del problema. Un modelo de dominio se representa mediante diagramas de clases, diagramas de objetos, o mediante ambos. Los primeros presentan de forma esttica las clases del dominio y sus relaciones; los segundos muestran interacciones entre objetos concretos. Si los trminos del modelo son poco habituales (por ejemplo, trminos mdicos), el modelo de dominio suele incluir un breve glosario con todos ellos.
Las etapas del anlisis OO son stas: 1) Identificacin de las clases del dominio. Ms adelante veremos dos tcnicas para identificarlas. 2) Elaboracin del glosario de trminos procedentes del dominio (esta etapa suele omitirse si los trminos son de uso comn). 3) Identificacin de las relaciones o asociaciones entre las clases. 4) Identificacin de los atributos o propiedades de las clases. Desde la perspectiva del anlisis, un atributo de una clase indica que todos los objetos de esa clase tienen ese atributo. 5) Organizacin de las clases (mediante jerarquas). 6) Perfeccionamiento del modelo obtenido. El modelo obtenido por el anlisis OO se expresa en el lenguaje del cliente y del usuario, no depende de ningn entorno informtico y no considera las restricciones de implementacin. Sobre estas restricciones, llamadas requisitos no funcionales, volver ms adelante. Las clases del anlisis son clases conceptuales, no de software.
ANLISIS
Clientes
Dominio
Problema Usuarios Entrevistas con expertos en el dominio Anlisis OO Conocimiento del mundo real
Anlisis de requisitos
Lista de requisitos
Modelo de dominio OO
Figura 7. En ingeniera del software, el proceso de anlisis corresponde a esta figura.
Pgina 21 de 55
Figura 8. Metamodelo del anlisis de problemas empresariales: se usan los conceptos del anlisis para describir el anlisis. Aparecen algunos conceptos no mencionados antes (riesgo, recomendacin, oportunidad) porque este metamodelo corresponde a problemas empresariales, no de software. El diagrama se ha realizado con la herramienta Metis 3.6.
Nota: Aunque los trminos diagrama y modelo se usan casi siempre como sinnimos (yo incurro a menudo en esa identificacin), no significan exactamente lo mismo: un diagrama representa, a menudo parcialmente, un modelo. Un modelo puede describirse con varios diagramas y, a la vez, varios diagramas pueden representar un mismo modelo (siempre que sean consistentes). La diferencia de significado resulta importante si se trabaja con UML, pues ste especifica que slo hay un modelo de clases (incluido en el modelo estructural esttico), que puede describirse con varios diagramas de clases. Por lo tanto, aunque en UML una clase slo figura una vez en el modelo de clases, puede aparecer en varios diagramas de clases.
Para identificar las clases conceptuales de un dominio, suelen usarse dos tcnicas: la identificacin de sustantivos y la comparacin con una lista de categoras de clases. La tcnica de la identificacin de sustantivos extrae los sustantivos (nombres y grupos nominales) que aparecen en la descripcin del problema y considera que corresponden a clases candidatas. La tcnica de la comparacin con una lista de categoras de clases determina las clases candidatas de un dominio basndose en una lista de categoras de clases como la mostrada en la tabla 2, que procede de APPLYING UML AND PATTERNS: An Introduction to Object-Oriented Analysis and Design and the Unified Process, Second Edition [Craig Larman, 2002]. Asignando los conceptos de la descripcin del problema a las categoras de clases, se obtiene una lista de clases candidatas. Ambas tcnicas exigen un proceso de depuracin, que se acelera con la experiencia del analista. Dada una lista de sustantivos o clases candidatas, convendr aplicar las siguientes reglas de eliminacin: 1) Redundancia. Si varios sustantivos se refieren a la misma entidad, se debe elegir uno de ellos (el ms representativo). Por ejemplo, no tiene sentido mantener tres clases como Trabajador, Empleado y Asalariado. 2) Atributo. Los sustantivos que describen la estructura de las clases corresponden a atributos, no a clases. Por ejemplo, el cdigo de un libro es un atributo de una clase Libro, no una clase por s misma. 3) Irrelevancia. Los sustantivos sin relacin con el problema o el dominio no son relevantes. Por caso, las clases candidatas Mostrador del Hospital y Mquina de Caf resultan irrelevantes si se est elaborando una aplicacin para un hospital. Siempre se debe evitar la introduccin de clases no asociadas a los conceptos del dominio bajo estudio. 4) Accin. Los sustantivos correspondientes a acciones no originan clases. Por ejemplo, la clase candidata Clculo del IVA no es una clase. En todo caso, calcularIVA sera una operacin de alguna clase. 5) Estado. Los sustantivos que describen el estado de una entidad no corresponden a clases. Por ejemplo, Automvil Veloz no es una clase (la clase es Automvil).
Pgina 23 de 55
6) Frecuencia temporal. Los sustantivos que describen frecuencias de tiempo no corresponden a clases. Por ejemplo, en la frase Al cliente se le informa de su saldo cada semana, Semana no es una clase. 7) Entidad de hardware o de software. Los sustantivos que describen entidades de hardware o de software no generan clases (salvo que se est modelando un sistema de hardware o de software). Por ejemplo, en el dominio de una empresa, aunque haya un requisito como El cliente seleccionar mediante el teclado el producto que desea, Teclado no ser una clase. Sin embargo, una clase candidata CPU ser vlida si el dominio corresponde a componentes de hardware o a sistemas operativos. La identificacin de las relaciones entre las clases de un dominio se realiza a partir de las frases verbales presentes en la descripcin del problema y de nuestro conocimiento de ste. Las relaciones pueden ser explcitas (El usuario posee una tarjeta de crdito) o implcitas (asiento de avin significa que el avin contiene asientos; itinerario de vuelo significa que un vuelo sigue un itinerario). Categora de clase Objetos tangibles o fsicos Especificaciones, diseos y descripciones de las cosas Lugares Transacciones Lneas de las transacciones Papeles desempaados por las personas Contenedores de otras cosas Cosas dentro de un contenedor Otros sistemas informticos o electromecnicos externos al sistema Conceptos abstractos Organizaciones Hechos Reglas y polticas Catlogos Registro financieros, laborales, contratos y asuntos legales Manuales, documentos, artculos y libros Ejemplos Registro, Avin Especificacin del Producto Descripcin del Vuelo Tienda Venta, Pago, Reserva Lnea de Pedido Cajero, Piloto Tienda, Lata, Avin Artculo, Pasajero Sistema de Autorizacin del Pago por Tarjeta de Crdito Control de Trfico Areo Ansia Acrofobia Departamento de Ventas Venta, Pago, Reunin, Vuelo, Colisin, Aterrizaje Poltica de Reintegro Poltica de Cancelacin Catlogo de Productos Catlogo de Piezas Recibo, Contrato de Empleo, Registro de Mantenimiento Manual del Programa, Manual de Reparaciones
Tabla 2. Lista de categoras de clases. Se utiliza para proponer clases candidatas para un dominio (los ejemplos corresponden a los dominios de las tiendas y las reservas de vuelo). La tabla se ha traducido del libro de Craig Larman APPLYING UML AND PATTERNS, Second Edition.
En lugar de continuar hablando de anlisis, dominios, modelos y dems abstracciones, prefiero mostrarlos con un ejemplo. Se basa en mis estancias veraniegas, cuando nio, en la pequea biblioteca infantil de Soria que est junto a la rosaleda de la Alameda de Cervantes (http://www.ayto-soria.org/html/laciudad/rutas/). (Mi ta y mi abuela vean pasar por all a Don Antonio Machado, siempre tras la silla de ruedas en la que iba su mujer, Doa Leonor, tsica e impedida.). El ejemplo dice as:
Una pequea biblioteca infantil necesita un sistema informtico para gestionar los prstamos de libros (cada libro tiene un cdigo nico) y peridicos. El sistema controlar los prstamos y permitir buscar usuarios. Los socios de la biblioteca pueden sacar en prstamo hasta 3 libros, durante un tiempo mximo de 15 das (no pueden sacar peridicos). Los dos trabajadores de la biblioteca pueden, sin ser socios, sacar hasta 6 libros (por un mximo de 15 das) y 3 peridicos (por un mximo de 1 da). Por motivos legales (Ley de Proteccin de Datos) no se conservar informacin sobre los libros sacados por cada lector cuando se hayan devueltos. Dadas las escasas subvenciones que reciben las bibliotecas municipales pese al extraordinario trabajo que hacen y a la amenaza del pago de un canon por sus libros (http://www.derecho-internet.org/node/282), el sistema deber ser barato y podr ejecutarse en un Pentium II.
Como puede suponerse, ni la Ley de Proteccin de Datos (oficialmente, en Espaa es la Ley Orgnica 15/1999, de 13 de diciembre, de Proteccin de Datos de Carcter Personal) ni el canon de libros exista cuando yo andaba con pantalones cortos: permtame estas pequeas libertades cronolgicas. En este caso, el dominio del problema es la biblioteca; los expertos en el dominio, los trabajadores de la biblioteca. Tras hablar con ellos, averiguamos que desean sobre todo que el sistema registre los prstamos y devoluciones de libros y peridicos. La poltica de sanciones consiste en que, si el socio o el trabajador de la biblioteca no devuelve los libros o los peridicos en la fecha fijada, se le castiga con un da de sancin por libro/peridico y da de retraso; durante los das de sancin, no se puede sacar libros ni peridicos. Tambin descubrimos que los ejemplares de un mismo libro tienen cdigos correlativos, y que slo reciben un ejemplar de cada peridico. Por ltimo, averiguamos que para hacerse socio se precisa una fotocopia del DNI, dos fotos actuales (no valen fotocopias en color) y rellenar una ficha con los datos personales (nombre, apellidos, direccin, telfono); en el carn de socio figura un nmero de socio (nico) y los datos personales de la ficha. Que el sistema sea barato y se ejecute en un Pentium II es un requisito de implementacin, as que queda fuera del anlisis OO. Tras estudiar la descripcin del problema, aplicar una de las dos tcnicas de identificacin de clases y utilizar las reglas de eliminacin de clases candidatas, extraemos clases como SocioBiblioteca, TrabajadorBiblioteca, Libro, Ejemplar (un libro puede tener varios ejemplares) y Peridico. Se podran conservar las clases candidatas Sancin y Prstamo, pero consideramos que la informacin que contienen se encuentra en SocioBiblioteca y Ejemplar. Cada clase tiene sus correspondientes atributos. Por ejemplo, los atributos de SocioBiblioteca son DNI, Nombre, Direccin, Telfono y NmeroSocio. Las relaciones entre esas clases las obtenemos a partir de los siguientes hechos, extrados de la descripcin y de nuestro conocimiento sobre bibliotecas: Los libros tienen ejemplares. Los socios de la biblioteca sacan en prstamo ejemplares de libros. Los socios de la biblioteca devuelven ejemplares de libros. Los trabajadores de la biblioteca sacan en prstamo peridicos. Los trabajadores de la biblioteca devuelven peridicos.
Pgina 25 de 55
Para el dominio de la biblioteca, el modelo de anlisis (o conceptual) OO se representa con un diagrama de clases similar al de la pgina siguiente. El modelo de anlisis muestra cmo se relacionan entre s conceptos como socio de la biblioteca, peridico, trabajador de la biblioteca, libro y ejemplar. Los modelos de anlisis no son nicos: a un mismo dominio le pueden corresponder varios modelos vlidos. Dado un dominio, no existe un modelo de anlisis universal, perfecto o indiscutible (eso s, hay modelos ms tiles y completos que otros). Por ejemplo, en el caso de la biblioteca, podramos haber creado un modelo de anlisis donde existiera una clase Prstamo (clase de asociacin) para la relacin saca entre Libro y SocioBiblioteca. La multiplicidad indica cuntos objetos de una clase pueden vincularse, a travs de una asociacin, a un objeto de la clase asociada. El smbolo 0..* indica una multiplicidad de cero o varios. Es decir, un objeto Libro puede tener asociados cero o ms objetos Ejemplar a travs de la asociacin es ejemplar de. La multiplicidad 0 correspondera al caso en que hubieran desaparecido todas los ejemplares de un libro (por extravo o hurto, por ejemplo). Vista la asociacin es ejemplar de desde el lado Libro, la multiplicidad 1 indica que todo Ejemplar corresponde a un Libro, y slo a uno. La multiplicidad en la relacin saca entre las clases Ejemplar y TrabajadorBiblioteca describe que un trabajador puede sacar hasta 6 ejemplares (en un momento dado) y que un ejemplar puede estar sacado, en un momento dado, por un trabajador o por ninguno.
MODELO DE DOMINIO DE LA BIBLIOTECA

TrabajadorBiblioteca 0.. 1 0.. 1 saca/devuelve saca/devuelve 0.. 1 0..* Ejemplar 0.. 3 0.. 6 Peridico
Libro 1 es ejemplar de
saca/devuelve 0.. 1
SocioBiblioteca
Figura 8. Modelo de dominio producido al aplicar el anlisis OO a la biblioteca. En este caso, al modelo consta de un solo diagrama de clases. Por motivos de espacio, omito los atributos de las clases.
El ejemplo que he escogido es deliberadamente simple: el anlisis de un problema medianamente complejo requiere muchas entrevistas con los usuarios; y los modelos de anlisis OO tienen decenas o centenares de clases, lo que hace necesario emplear varios diagramas de clases. Con todo, ejemplifica bien en qu consiste el anlisis OO.
Muchas metodologas OO (RUP y UP, por ejemplo) usan casos de uso para especificar los requisitos del sistema que se quiere construir. Un caso de uso es una narracin que describe los pasos que el sistema realiza para dar a un usuario, sea persona u otro sistema, un resultado de inters. Los casos de uso capturan el comportamiento del sistema, sin entrar en detalles de implementacin. Consideremos, vaya por caso, un caso de uso correspondiente a la aplicacin de la biblioteca: CASO DE USO: SACAR EN PRSTAMO LIBROS 1) Un socio de la biblioteca llega al mostrador del bibliotecario, donde deposita su carn de socio y varios ejemplares que desea sacar en prstamo. 2) El bibliotecario introduce en el sistema el nmero de socio que figura en el carn. 3) El sistema verifica si el nmero de socio es valido. En ese caso, comprueba si tiene ejemplares en prstamo y si est sancionado. 4) El sistema muestra los datos personales del socio y emite un aviso si tiene ms de tres ejemplares prestados o si est sancionado. Si es as, el socio no puede llevarse nada en prstamo. 5) El bibliotecario introduce en el sistema los cdigos de los ejemplares. Cuando termina, informa al sistema de que ha acabado con los prstamos al socio en curso. 6) El sistema registra los ejemplares prestados. 7) El bibliotecario entrega los ejemplares al socio.
El caso de uso anterior permite extraer algunos requisitos funcionales del sistema (por ejemplo, El sistema emite un aviso si el usuario tiene ms de tres ejemplares prestados o si est sancionado y El sistema registra los ejemplares como prestados al socio). Los requisitos funcionales son aquellos que expresan, desde la perspectiva de un usuario, qu debera hacer el sistema. Por ejemplo, un requisito funcional bastante tpico es El sistema generar listados ordenados por orden alfabtico. Los requisitos no funcionales (o tcnicos) definen cmo se implementa el sistema; es decir, especifican cmo hay que construir internamente el sistema para cumplir los requisitos funcionales. Los requisitos no funcionales pueden ser de muchos tipos: concurrencia, sistema operativo, memoria disponible, velocidad, persistencia de los objetos, distribucin del sistema... Veamos varios requisitos no funcionales bastante comunes: La aplicacin funcionar con menos de 2 MB de memoria RAM. El sistema usar TCP/IP para enviar y recibir mensajes. El sistema se ejecutar en una estacin de Sun con el sistema operativo Solaris 8.0.
Pgina 27 de 55
La aplicacin se programar en un lenguaje OO. Los datos se guardarn en Oracle.
Los casos de uso suelen usarse, adems de para capturar requisitos funcionales, para obtener clases conceptuales del dominio (en el caso de uso anterior podramos identificar clases como Ejemplar, SocioBiblioteca). Las dos tcnicas que vimos antes para identificar clases se pueden emplear con los casos de uso. Los casos de usos no estn orientados a objetos: expresan las funciones del sistema (requisitos funcionales) sin emplear objetos y clases. Si los casos de uso fueran una tcnica OO, los ejemplares del paso 6 se registraran a s mismos como prestados cuando recibieran un mensaje de algn objeto. No obstante, son una tcnica muy habitual y til para extraer las clases conceptuales del dominio. Debo sealar que unos pocos autores expresan sus dudas sobre la eficacia de los casos de uso en el anlisis OO. Por ejemplo, Meyer escribe en Object Oriented Software Construction [Bertrand Meyer, 1988]:
Excepto en el caso de un equipo con mucha experiencia en diseo (que haya construido con xito sistemas de varios miles de clases, cada uno en un lenguaje OO puro), no confe en los casos de uso como una herramienta para el anlisis y diseo orientado a objetos.
En mi opinin, resulta adecuado trabajar con casos de uso si se quiere identificar clases y objetos; pero uno no debe confiar slo en ellos: en el anlisis OO hay que prestar atencin tambin a los requisitos no expresados en forma de casos de uso, y a las conversaciones con expertos, clientes y usuarios. Con los casos de uso, se hace muy difcil saber cuando se han descubierto todas las clases del dominio. Las clases conceptuales de un dominio, que provienen del anlisis OO, siempre son ms estables que los casos de uso, puesto que las funciones de un sistema suelen cambiar.
3.2.3 El diseo OO El diseo es un proceso que usa los resultados del anlisis para generar una especificacin que implemente un sistema o un producto. El anlisis trabaja en el espacio del problema; el diseo, en el espacio de la solucin. Durante la etapa de anlisis, lo fundamental es qu necesita hacer el sistema; cuando se aborda el diseo, lo importantes es cmo construirlo. En el caso del software, el diseo genera dado un entorno informtico y una lista de requisitos un modelo de software (modelo de diseo) que detalla cmo debe hacer las cosas el sistema para cumplir los requisitos y, en definitiva, solucionar el problema que se plantea en el dominio de inters. En el diseo se consideran las restricciones derivadas de la implementacin (requisitos no funcionales o tcnicos). Por tanto, los modelos de diseo dependen del entorno informtico ordenadores personales, estaciones de trabajo, entornos distribuidos, agendas electrnicas, sistemas operativos, lenguajes de programacin donde se vaya a implementar el sistema. En el diseo hay que contestar preguntas como stas: Cmo se puede distribuir entre varios ordenadores la aplicacin, con el fin de que se distribuyan equitativamente las peticiones que recibe cada ordenador?
Pgina 28 de 55
Qu componente de acceso a bases de datos es el ms conveniente para la aplicacin? Cmo puede ejecutarse este mtodo en un tiempo mximo de 30 milisegundos? Cmo puede utilizarse ms eficientemente Java en la aplicacin?
El diseo OO usa los resultados del anlisis OO y del anlisis de requisitos para producir un modelo de diseo basado en clases y objetos de software; a diferencia de lo que sucede en el anlisis OO, los objetos y clases del diseo OO no modelan entidades del mundo real, sino de software. La diferencia fundamental entre anlisis y diseo OO es el nivel de detalle: el diseo refina las clases conceptuales del anlisis hasta convertirlas en clases de software implementables en un lenguaje OO. Durante el diseo OO, hay que completar pasos como stos: a) Representacin de las clases. Para cada clase hay que decidir si se representa mediante tipos primitivos (int, float, double...) o mediante otras clases ms simples. Por ejemplo, un objeto Lnea puede representarse mediante cuatro datos de tipo float o double (x1, y1, x2, y2) o mediante dos objetos Punto. b) Diseo de los algoritmos que implementen las operaciones de las clases. Para ello hay que a) elegir los algoritmos, considerando factores como la complejidad computacional, la flexibilidad, la facilidad de implementacin y la comprensibilidad; b) seleccionar las estructuras de datos pertinentes para los algoritmos (pilas, colas, rboles, etc.); c) definir las clases y operaciones internas que se necesitarn para almacenar los datos intermedios generados por los algoritmos. c) Reorganizacin de las clases y operaciones para aumentar, si es posible, la herencia. Vase 4.4 para una introduccin a la herencia. d) Diseo de las asociaciones entre clases. En la fase de diseo hay que establecer cmo se implementarn las asociaciones o relaciones (punteros, conjuntos de punteros, diccionarios...). Todo modelo de diseo OO especifica lo siguiente: Los tipos de objetos (clases) que necesita el sistema para resolver el problema. Deben especificarse sus atributos, operaciones y relaciones. Las interacciones entre los objetos (instancias), las cuales cambian con el tiempo. Por ejemplo, un objeto Mecnico puede estar arreglando un objeto Automvil y luego puede preguntar a un objeto Cliente sobre la forma de pago que desea.
El primer punto corresponde al modelo esttico; el segundo, al dinmico.
Pgina 29 de 55
Nota: Tal como he escrito al principio de este subapartado, el diseo OO toma los resultados del anlisis OO con el fin de generar un modelo lo bastante detallado como para ser implementado en un lenguaje OO. Ahora bien, en la prctica, la separacin entre anlisis y diseo OO no siempre resulta tan tajante: a menudo hay un solapamiento entre ambas actividades. Abordar las ventajas de ese solapamiento en 3.3. La frontera entre anlisis y diseo OO es sumamente borrosa en las metodologas iterativas de desarrollo de software. En una metodologa iterativa, el desarrollo se estructura en una serie de pequeos proyectos cortos, de duracin fija (2-3 semanas, por ejemplo). Estos proyectos se llaman iteraciones; cada iteracin produce un sistema o subsistema que puede probarse, ejecutarse e integrarse en un sistema mayor. Como cada iteracin tiene sus tareas de anlisis, diseo e implementacin, en cada una se mezcla el anlisis con el diseo. En estas metodologas tambin se mezcla el diseo con la implementacin, lo cual no es un inconveniente, ms bien al contrario; pues la implementacin desarrollada en una iteracin se usa para encontrar errores en el diseo, que se corrigen en la siguiente iteracin. Por regla general, cuanto ms grande es el proyecto de software que se aborda, ms ntida aparece la separacin entre anlisis y diseo, y entre diseo e implementacin.
Las clases conceptuales del modelo de dominio generado por el anlisis OO suelen continuar en el diseo OO como clases de entidad (clases de software que contienen informacin persistente); tambin las relaciones entre las clases del modelo de dominio OO suelen permanecer en el diseo OO. Adems de las clases de entidad, en el diseo OO hay que aadir a menudo clases de interfaz (clases de software que modelan la relacin entre el sistema y los usuarios externos, ya sean stos personas o sistemas) y clases de control (clases de software que se usan para representar la coordinacin entre clases). Las clases de interfaz suelen ser abstracciones de ventanas, formularios, paneles, sensores, teclados, ratones, impresoras, tarjetas de red... Las clases de control suelen encapsular el control de un caso de uso o el sistema completo; especifican qu mensajes deben intercambiar los objetos, y en qu orden, para que el sistema cumpla una o ms funciones. Por ejemplo, al caso de uso Sacar en prstamo libros se le podra asignar una clase de control SacarLibro que coordinara las acciones que deben llevar a cabo los objetos Libro, Ejemplar y SocioBiblioteca para que el usuario pueda llevarse en prstamo un libro. La clase Biblioteca de la figura 10 es una clase de control: representa al sistema informtico de la biblioteca. Adems de las clases de interfaz y de control, un diseo OO suele necesitar clases definidas de serie en el lenguaje donde vaya a implementarse el diseo. Por ejemplo, los objetos Libro de la biblioteca se podran guardar en una clase Vector o ArrayList de Java, clases ausentes en el modelo de anlisis. Estas clases se emplean para implementar colecciones de objetos en la memoria de un ordenador o computador y, por ende, sus propiedades no derivan del dominio del problema ni del mundo real.
Pgina 30 de 55
A veces, en el anlisis y diseo OO se usan las tarjetas CRC (ControlResponsabilidad-Colaborador). Estas tarjetas son pequeos trozos de papel o cartulina donde se describen las clases del sistema que se desea construir. Cada tarjeta incluye el nombre de una clase, las responsabilidades de sta y las clases con las que colabora. Una responsabilidad es una descripcin breve de lo que hace la clase; y corresponde a algo que la clase necesita conocer (p. ej., nmeros de telfono) o a una accin que debe ejecutar (p. ej., dar de alta a un cliente). En caso de duda sobre si algo es o no una responsabilidad, se aplica el criterio de que una responsabilidad debe usarse en otras partes del sistema. Una tarjeta CRC debe contener ms de una responsabilidad (en caso contrario, habra que rechazar la clase que contiene) y no ms de tres o cuatro responsabilidades (si no es as, habra que repartir las responsabilidades de la clase entre ms clases). Las clases colaboradoras son aquellas que ayudan a una clase a cumplir sus responsabilidades. Cada clase colaboradora tiene su propia tarjeta CRC. La principal funcin de las tarjetas CRC consiste en establecer cmo se coordinan las clases del sistema para cumplir los requisitos. Estas tarjetas ofrecen la ventaja aadida de que la informacin sobre colaboraciones entre clases puede enseguida modelarse mediante diagramas UML de secuencia y de colaboracin. Las tarjetas CRC se usan normalmente en sesiones donde participan analistas, usuarios y desarrolladores; son una buena madera de romper el hielo con la gente sin experiencia en la OO. El libro The CRC Card Book [David Bellin & Susan S. Simone, 1997] es la mejor referencia para esta tcnica.
Pgina 31 de 55
EJEMPLO DE TARJETA CRC

Nombre de la clase: SocioBiblioteca Responsabilidades: Almacena los datos personales del socio Almacena la informacin sobre los prstamos en vigor Almacena informacin sobre sanciones Colaboradores: Ejemplar
Figura 9. Ejemplo de una tarjeta CRC. Las responsabilidades de una clase y sus clases colaboradores resultan muy tiles a los diseadores OO. El objetivo de las tarjetas CRC no es entrar en detalles de implementacin, sino capturar el propsito de la clase en unas pocas lneas. Por eso son pequeas, para que no se pueda escribir mucho. Una tarjeta CRC no debe asignar a una clase ms de tres o cuatro responsabilidades.
Pgina 32 de 55
Adems de ayudar en el anlisis OO, los casos de uso resultan tiles para el diseo OO, pues las funciones representadas por los casos de uso se modelan como colaboraciones entre los objetos del sistema.
La figura siguiente muestra un diagrama de diseo correspondiente al problema de la biblioteca. Est orientado a objetos, pues muestra objetos que se envan mensajes entre s para satisfacer los requisitos del sistema.
DIAGRAMA CORRESPONDIENTE AL MODELO DE DISEO DE LA BIBLIOTECA

bibliotecario :TrabajadorBiblioteca biblioteca :Biblioteca socio :SocioBiblioteca ejemplar :Ejemplar libro :Libro
1: sacarLibro(numeroSocio, codigoEjemplar) 2: puedeSacar() Comprueba si el socio tiene ya el mximo nmero de libros permitidos o si est sancionado 3: sacar(codigoEjemplar) 3.1: sacar() 3.2: sacar()
Figura 10. Diagrama parcial de un modelo de diseo OO (es un diagrama de secuencia UML). La figura modela los pasos necesarios para que un socio de la biblioteca saque en prstamo un libro. Cuando un programador experto en UML ve un diagrama de diseo como ste, tiene una idea bastante clara de cmo traducirlo a cdigo. La clase Biblioteca es una clase de control: representa al sistema que se desea construir para gestionar la biblioteca. Evidentemente, este diagrama de secuencia representa slo una pequea parte del modelo de diseo correspondiente a la aplicacin completa.
Pgina 33 de 55
3.2.4 La programacin OO Cuando se consideran sistemas de software, la orientacin a objetos consiste en el anlisis OO, el diseo OO y la programacin OO. La programacin OO es el proceso que genera una aplicacin a partir del diseo OO. Dicho en otras palabras, la POO materializa fsicamente los diseos OO, que a su vez proceden del anlisis OO. La fuerza de la POO radica en que la comprensibilidad y la facilidad de mantenimiento de los programas aumentan cuando se descomponen en clases. El resultado de la POO es una aplicacin capaz de ejecutarse en un entorno informtico. A veces se dice que el resultado es el cdigo fuente de la aplicacin. Esto no es del todo cierto: sus clientes no quedarn muy satisfechos si les da un listado con el cdigo de la aplicacin o un archivo de texto con el cdigo. En realidad, el cdigo fuente es un modelo que usan los programadores para comunicarse entre ellos, y que puede ser traducido fcilmente (con un interprete o un compilador) a un lenguaje inteligible para los ordenadores.
Comentarios impopulares (no diga que no avis): Conservar la documentacin generada durante el anlisis y diseo de un sistema (glosarios, diagramas de clases, de objetos, etc.) reduce los gastos cuando hay que modificarlo o sustituirlo. En el mundo del software, las plataformas y los lenguajes cambian mucho, pero los requisitos de los sistemas son ms permanentes. Cuando hay que cambiar un sistema por otro, suele empezarse de cero (se tira toda la documentacin del sistema anterior, suponiendo que la hubiera). As se desperdicia el anlisis y diseo hecho para el sistema anterior, y se sigue a pie juntillas la inmortal frase Parece que jams hay tiempo ni dinero para hacerlo bien a la primera, pero siempre hay tiempo y dinero para volver a hacerlo. En los sistemas de software empresariales sistemas ERP, aplicaciones de gestin, de contabilidad) se calcula que, cuando se cambia un sistema por otro, se mantiene el 70-80% de los requisitos (dar de alta a clientes, registrar pedidos, guardar transacciones, comprobar pagos, etc.). En el caso de los modelos conceptuales, el 95% de las clases no cambia. Algunas metodologas de ingeniera del software dedican poco tiempo a la documentacin, pues es costosa. El resultado final es que, cuando hay que modificar sustancialmente el sistema o sustituirlo por otro, hay que empezar de cero el anlisis y diseo, y el cliente debe volver a pagarlo, aunque sus requisitos apenas hayan variado. Como puede suponerse, esto no molesta, ms bien al contrario, a las consultoras de software; pero s a los clientes y a quienes intentamos mejorar la competitividad de las pequeas y medianas empresas europeas. Dentro de esas metodologas, algunas reducen al mnimo el anlisis y diseo, y se centran en la programacin. Este enfoque puede funcionar en proyectos pequeos, pero no en proyectos grandes o medianos, ni en aquellos en que se exigen caractersticas como escalabilidad o velocidad. Estas caractersticas no surgen directamente de la programacin, sino que deben ser tenidas en cuenta desde el principio.
Pgina 34 de 55
3.3 Comparacin de la OO con la metodologa estructurada

Antes de comenzar con los fundamentos de la orientacin a objetos, conviene mencionar a su oponente en el desarrollo de sistemas: la metodologa estructurada (tambin conocida como funcional o algortmica). Esta metodologa toma una tarea general que se necesita llevar a cabo (como permitir que el usuario gestione un almacn) y la divide en subtareas (como retirar un pedido y dar entrada a los nuevos productos). Una persona que utilice la metodologa estructurada dividir el problema bajo estudio identificando una serie de procesos, manipulaciones o tratamientos de datos (llamados funciones o procedimientos en las fases de diseo e implementacin) que, organizados de modo que puedan llamarse unos a otros, proporcionen la solucin. En la metodologa estructurada existe siempre una separacin entre datos y procesos: los procesos manipulan y usan datos, pero no se integran con ellos. La metodologa estructurada aplicada a los sistemas de software (anlisis estructurado + diseo estructurado + programacin estructurada) se basa en la abstraccin por descomposicin funcional o por procedimientos: el problema estudiado se descompone en una serie de capas sucesivas de procesos, hasta que finalmente se descompone en procesos relativamente fciles de implementar y codificar (desarrollo top-down). El programa se divide en unidades lgicas (mdulos) mediante el uso de funciones o procedimientos; los detalles ms internos del programa residen en los mdulos de ms bajo nivel, y los mdulos de ms alto nivel se encargan del control lgico del programa. Considerar aqu un ejemplo de diseo estructurado. Imagine, vaya por caso, que debe escribir un programa para mostrar por pantalla un catlogo de muebles, teniendo en cuenta que las descripciones de los muebles (dibujos con las cotas correspondientes) se almacenan en una base de datos. El usuario puede seleccionar qu muebles desea ver en la pantalla. Para mostrar las descripciones de los muebles, el diseo estructurado considerara la siguiente secuencia de pasos: 1) Se accede a la base de datos. 2) Dentro de la base de datos, se buscan los muebles que desea ver el usuario. 3) Se abre una lista de muebles. 4) Se aaden a la lista todos los muebles encontrados en el paso 2. 5) Se ordena la lista (por tipo de mueble, p. ej.). 6) Se muestra por pantalla, uno detrs de otro, el dibujo de cada mueble incluido en la lista. Cada paso podra dividirse, a su vez, en otros. Por ejemplo, el paso 6 podra escribirse as: 6.1) Se lee de la base de datos la posicin (x, y) de cada punto del dibujo del mueble. 6.2) Se llama a la funcin grfica encargada de dibujar los muebles, dndole como argumento las coordenadas del punto antes ledo. 6.3) Se repiten los pasos 6.1 y 6.2 hasta que se hayan ledo todos los puntos de la descripcin del mueble.
Este ejemplo muestra por qu a la metodologa estructurada se le llama tambin funcional: divide el problema en pasos, cada uno con una funcin clara (en el ejemplo, acceder a la base de datos, buscar en ella los muebles seleccionados, ordenarlos, dibujarlos, etc.). De una manera orientada a objetos, el problema del catlogo electrnico se solucionara as: 1) El programa crea una instancia del objeto que representa a la base de datos. 2) El programa pide al objeto base de datos que encuentre los muebles que quiere ver el cliente. 3) El programa crea un objeto lista con los muebles. 4) El programa crea instancias de los muebles encontrados en el paso 2 y los aade al objeto lista. 5) El programa pide al objeto lista que se ordene (al hacerlo, ordena los objetos que contiene). 6) El programa pide a la lista que se muestre por pantalla. 7) La lista pide a cada objeto mueble dentro de ella que se muestre a s mismo por pantalla. 8) Cada objeto mueble se dibuja en la pantalla, con las cotas correspondientes. El uso de objetos y la asignacin de responsabilidades a stos son caractersticas inexistentes en la metodologa estructurada o funcional. La metodologa estructurada resulta til para producir pequeos programas y mdulos. Muchas aplicaciones informticas de gestin la utilizan, pues usan mayoritariamente pseudobjetos u objetos que no pueden considerarse objetos de pleno derecho (por ejemplo, objetos sin atributos o sin operaciones), generalmente asociados a las estructuras tradicionales de datos. La principal diferencia entre la programacin OO y la programacin estructurada radica en sus representaciones del dominio bajo estudio. La programacin estructurada (C, Pascal) obliga al desarrollador a trabajar con abstracciones procedentes del mundo de la informtica: if/else, do/while, loop, etc. En cambio, la POO utiliza el vocabulario del dominio; por ejemplo, si implementramos la aplicacin para gestionar la biblioteca apareceran clases de software como Libro, Ejemplar, etc. La conversin de los trminos del anlisis OO en construcciones de lenguajes de programacin OO es bastante directa, lo que constituye una importante ventaja sobre la metodologa estructurada. Resulta innegable que el salto conceptual entre el mundo real y la programacin es menos brusco en la POO que en la programacin estructurada, basada en algoritmos. Como puede apreciarse, la POO simula en software las entidades del mundo real. Simular es la palabra exacta: los primeros lenguajes OO (SIMULA I y Simula 67), creados en la dcada de 1960, eran lenguajes de simulacin. SIMULA I (1962-65) y Simula 67 (1967) surgieron con el fin de desarrollar herramientas que sirvieran para la descripcin y simulacin de sistemas fsicos (por ejemplo, motores) y de sistemas persona-humana. A diferencia de SIMULA I, Simula 67 era un lenguaje de programacin
Pgina 36 de 55
general, si bien poda especializarse para muchos dominios, incluyendo la simulacin de sistemas. A la hora de simular sistemas fsicos, los creadores de los lenguajes Simula (OleJohan Dahl y Kristen Nygaard, quienes ganaron en 2002 el premio Turing por su trabajo) se enfrentaban a dos grandes problemas. De un lado, los programas que necesitaban escribir eran muy largos y, por ende, difciles de entender. De otro, haba que modificarlos sustancialmente cuando se cambiaba el sistema bajo estudio, e incluso cuando haba que probar varias simulaciones de un mismo sistema (con distintas piezas, p. ej.) para elegir la ptima. Para solucionar ambos problemas, Dahl y Nygaard decidieron disear sus programas de simulacin inspirndose en los objetos fsicos del sistema real. As, si en un motor haba 20 componentes, el programa que lo simulaba contaba tambin con 20 mdulos, uno por cada componente. Esta forma de proceder resolva los dos problemas planteados antes. Por un lado, los problemas podan descomponerse en componentes sencillos (clases), lo que aumentaba su legibilidad. Por otro, si se quera simular cmo reaccionaba el sistema ante el cambio de alguna pieza o componente, slo deba modificarse un componente, no todo el programa, como suceda en la metodologa estructural. Ms an: los componentes generados para la simulacin de un sistema podan usarse como ladrillos para simulaciones de otros sistemas. La estrategia de asignar un objeto de software a cada objeto o pieza real parece hoy algo natural e inmediato; pero fue revolucionario en una poca en que la metodologa estructurada campaba a sus anchas. Mientras que sta generaba programas mediante llamadas sucesivas entre funciones o procedimientos, en los que los datos y las funciones permanecan separados, la naciente orientacin a objetos se centraba en disear los programas como colaboraciones entre objetos, donde se agrupaban datos y operaciones. Como curiosidad, muestro aqu el cdigo correspondiente a una clase Saludo de Simula 67. Por mucho que creamos que Eiffel, Java o C#, o el lenguaje que uno prefiera, son la cumbre de la orientacin a objetos, todas las caractersticas fundamentales de los lenguajes OO estn en los lenguajes Simula. Definicin de la clase Saludo Begin Class Saludo; Begin OutText("Hola. Como lenguaje soy una reliquia, pero la POO naci conmigo."); OutImage; End; REF(Saludo) mi_saludo; Mi_saludo :- New Saludo; End; Se crea un objeto Saludo
Pgina 37 de 55
Enfoque estructurado
EnviarMensaje(texto: String)
Enfoque orientado a objetos

Objeto Mensaje
Figura 11. El dibujo muestra el envo de un mensaje de un ordenador a otro. En el enfoque estructurado, el mensaje se enva como una cadena de texto; para mostrarlo, el ordenador receptor debe saber cmo procesar el texto. En el enfoque OO, se enva un objeto Mensaje, el cual sabe qu debe hacer para mostrarse en el ordenador receptor. El objeto Mensaje lleva consigo datos (texto) y operaciones. Cuando el objeto llegue al ordenador receptor, se ejecutarn las operaciones del objeto encargadas de mostrar el texto de mensaje. En el primer caso, se envan slo datos; en el segundo, datos y cdigo.
En la tabla 3 se aprecia uno de los defectos ms comnmente sealados por los crticos de la metodologa estructurada: la separacin clara e insalvable entre el anlisis y el diseo, es decir, entre lo que se quiere que haga el sistema y cmo lo hace. En la OO, la frontera entre el anlisis y el diseo es ms difusa (vase la nota de la pgina 30), y los objetos se introducen desde el principio. Cuanto ms detallado es el anlisis, ms inmediato es el paso a la implementacin, lo que reduce el tiempo dedicado al diseo. Como he mencionado hace en las dos pginas anteriores, la OO hace ms natural pasar del anlisis a la implementacin que la metodologa estructurada: el salto conceptual del anlisis a la implementacin es menor en la OO. En las metodologas OO, todas o casi todas las clases obtenidas en el anlisis se usan para el diseo y la implementacin.
Pgina 38 de 55
Metodologa estructurada Etapa de anlisis: se determina qu debe hacer el sistema que se desea construir.
Metodologa orientada a objetos Etapa de anlisis: se determina qu debe hacer el sistema que resolver el problema y se extraen las clases y objetos del dominio del problema. Se modela el dominio del problema mediante la notacin OO. Etapa de diseo: se extraen funciones o Etapa de diseo: se usa el anlisis OO del procedimientos (muy vinculados con los problema para generar una especificacin datos con los que se va a trabajar) y se que implemente el sistema teniendo perfecciona el diseo. presente las restricciones impuestas por la Esta fase no puede omitirse. implementacin. Muchas veces, esta fase puede simplificarse si se parte de un anlisis OO detallado. Etapa de programacin: se Etapa de programacin: se implementan implementan las funciones en un los objetos en un lenguaje de programacin lenguaje de programacin adecuado. orientado a objetos. Tabla 3. Comparacin entre el anlisis, el diseo y la programacin en ambas metodologas.
Dominio
Anlisis de requisitos Anlisis OO Problema Como el anlisis OO simplifica y acelera el diseo OO, se favorece la creacin de prototipos rpidos sobre los que hacer pruebas
module A
Modelo de anlisis OO
module B
module C
module D module E
b f a d
Diseo OO
Modelo de diseo OO
Programacin OO
(defun (rc s- writ e (if (error- occ urred (writ e- current - file)) (if buffer- is- modified (do- c hec kout (c ur rent - buffer- name) ))) (novalue)) (do- c heckout c - buf co- fname (set q c - buf (arg 1)) (set q c o- fname (ar g 2)) (if ( | (file- exist s (c oncat " RCS/ " c - buf " .v" )) (progn (messsage " please wait , now looking " ) (exec ut e- monit o- c ommand (c onc at ... (message " done" )
Programa OO
Figura 12. Muchas veces, la OO permite construir prototipos rpidos, pasando rpidamente por la etapa de diseo. En el enfoque estructurado, la etapa de diseo no puede simplificarse.
Algunos autores consideran que la OO ha evolucionado a partir de la metodologa estructurada; otros, que es un salto revolucionario, cualitativo ms que cuantitativo. Desde luego, los partidarios del salto revolucionario suelen ser firmes partidarios de la OO. As, en la obra Object-Oriented Modeling and Design [James Rumbaugh et al, 1991] se considera que el diseo orientado a objetos es una nueva forma de pensar en los problemas, mediante modelos sobre conceptos del mundo real; y en Software Engineering: A Practitioner's Approach 5th edition [Roger S. Pressman, 2001], Pressman refiere que
a diferencia de otros mtodos de diseo, el diseo orientado a objetos da como resultado un diseo que interconecta los objetos de datos y las operaciones, de forma que modulariza la informacin y el procesamiento en vez de slo la informacin. La naturaleza del diseo orientado a objetos est ligada a tres conceptos bsicos: abstraccin, modularidad y ocultacin de la informacin.
Mi opinin, dado que no hay un acuerdo unnime, se resume en que la OO utiliza abstracciones ausentes en la metodologa estructurada, que no admiten equivalencia en sta. Ntese que estoy hablando en trminos conceptuales, no de lenguajes de programacin. Tericamente, todo lo que puede hacer un lenguaje OO podra hacerlo un lenguaje estructurado. De hecho, las primeras versiones de C++ utilizaban un preprocesador que, antes de la compilacin, traduca el cdigo fuente a C. Incluso un lenguaje puro OO como Eiffel permite la traduccin del cdigo Eiffel a cdigo C.
Pgina 40 de 55
4. Fundamentos de la orientacin a objetos

La orientacin a objetos se fundamenta en los siguientes principios: Abstraccin Modularidad Encapsulacin Jerarqua
4.1 Abstraccin
La abstraccin es una aproximacin que hace hincapi en los aspectos ms importantes de algo, sin preocuparse por los detalles menos relevantes. De acuerdo con el Dictionary of Object Technology: The Definitive Desk Reference [Donald Firesmith, & Edward Eykholt., 1995], la abstraccin es Cualquier modelo que incluye los aspectos ms importantes, esenciales o distinguibles de algo mientras suprime o ignora los detalles menos importantes, inmateriales o que pueden distraer. La abstraccin es especfica del dominio. Por ejemplo, la abstraccin Persona es distinta en un dominio de censos electorales que en un dominio hospitalario. Quizs el ejemplo ms grfico de lo que es una abstraccin lo d el cuadro La Trahison des Images (La traicin de las imgenes), del pintor surrealista belga Ren Magritte (1898-1967). En l aparece dibujada una pipa y bajo ella aparece la frase Ceci nest pas une pipe (Esto no es una pipa), escrita con caligrafa escolar. Efectivamente, el dibujo es una abstraccin o representacin conceptual de una pipa, no una pipa (cun sutiles eran los surrealistas). En el cuadro se ha perdido la tridimensionalidad de la pipa real, sus pequeas imperfecciones, pero se han mantenido la mayor parte de sus caractersticas fundamentales (forma, etc.). Si se desea explicar alguien qu forma tiene una pipa, el cuadro de Magritte es una buena abstraccin o un buen modelo de una pipa real. No sera una buena abstraccin si, verbigracia, se quisiera fabricarla en serie (se desconocen las dimensiones y la madera de la que est hecha). En la ingeniera del software y en la OO es fundamental partir de buenas abstracciones o modelos del problema que vaya a abordarse.
Pgina 41 de 55
Figura 13. Cuando la abstraccin se confunde con la realidad: La traicin de las imgenes (1926), de Ren Magritte . Es esto una pipa? Si fuera de verdad una pipa, no debera poder encenderse y echar humo?
4.2 Modularidad
Es la propiedad que tienen ciertos productos (o procesos) de descomponerse en subproductos (o subprocesos) ms sencillos y manejables. Por ejemplo, un productos es modular si puede fabricarse a partir de componentes estandarizados intercambiables. Segn el Dictionary of OT, la modularidad es La descomposicin lgica de las cosas (por ejemplo, responsabilidades y software) en agrupaciones simples, pequeas (por ejemplo, requisitos y clases, respectivamente), que aumentan las posibilidades de lograr las metas de la ingeniera de software. Cuando nos restringimos a software, un mdulo es un conjunto de sentencias bajo el paraguas de un nombre por el cual puede ser llamado o invocado. Los mdulos son la unidad de programacin. En Java, una clase constituye un mdulo. Aunque no aparecen en la definicin del Dictionary of OT, las caractersticas deseables de un mdulo, las que aumentan su modularidad, seran las siguientes: Alta cohesin. La cohesin mide el grado de relacin funcional interna de los componentes de un mdulo. Bajo acoplamiento. El acoplamiento mide la interconexin entre mdulos.
Pgina 42 de 55
Ambos conceptos (cohesin y acoplamiento) no son absolutamente rgidos y no admiten una cuantificacin milimtrica. Adems, no son totalmente independientes: generalmente aunque no siempre una alta cohesin de un mdulo implica bajo acoplamiento respecto a otros.
4.3 Encapsulacin
La encapsulacin es el ocultamiento de la informacin. Segn el Dictionary of OT, es La localizacin fsica de las propiedades dentro de una sola abstraccin de caja negra que oculta su implementacin (y las decisiones asociadas de diseo) tras una interfaz pblica. La abstraccin de caja negra es utilizada ampliamente en fsica, electrnica e informtica, y consiste en esconder todos los detalles internos del sistema que se estudia bajo una caja negra imaginaria, cuando sea ms importante comprender qu hace el sistema que cmo lo hace. La encapsulacin es como introducir el sistema dentro de una caja negra con dos ranuras llamadas Entrada y Salida. Por ejemplo, en metrologa, cuando quiere calibrarse un dinammetro, no se estudia la incertidumbre que proporciona cada circuito, cada muelle, cada parte mvil, (entre otras cosas, porque el problema se tornara casi inabordable) y luego se combinan para obtener la incertidumbre del aparato. En la prctica, lo que se hace es considerar el dinammetro como una caja negra y se calibra viendo las lecturas (Salida) que da frente a fuerzas patrn (Entrada), olvidando sus componentes internos. As, por poner otro ejemplo lejano al campo de la informtica, un complejo circuito electrnico que forme parte de un sistema mayor puede ser substituido imaginariamente, para facilitar el estudio del sistema completo, por una caja negra que recibe una seal elctrica y devuelve otra. Es ms, el circuito podra caracterizarse por su funcin de transferencia (lo que hace) sin que fuera necesario conocer la forma en que modifica la seal de entrada (cmo lo hace) ni sus componentes. Del mismo modo, cuando en Java se utiliza la clase Vector, no es necesario saber qu operaciones internas realiza para aadir o eliminar elementos; es ms, si se necesitara conocerlas se estara violando el principio de encapsulacin. En los lenguajes OO, la encapsulacin garantiza que los usuarios de un objeto no puedan modificar el estado del objeto sin usar su interfaz. Es decir, no pueden cambiarlo de maneras no fijadas de antemano. En un objeto bien diseado, los otros objetos slo pueden interaccionar con l mediante su interfaz. Desde el punto de vista de la ingeniera de software, la encapsulacin ser correcta cuando la interfaz que se muestra al pblico cumpla las tareas que desea el cliente y no ensee ms de lo que ste precisa. Una buena encapsulacin separa siempre las vistas que del sistema tienen el constructor y el usuario.
Pgina 43 de 55
Seal entrada
La caja negra oculta los componentes internos (la implementacin)
Seal salida
Miguel ngel Abin, Nov. 2002
Figura 14. La encapsulacin es una herramienta poderosa en muchos campos
Resulta llamativo que el trmino encapsulacin provenga, precisamente, de la ingeniera electrnica. Esta coincidencia terminolgica, al igual que el ejemplo del circuito electrnico de la figura 5, no es ni mucho menos casual. La ingeniera electrnica aplicada a la construccin de ordenadores siempre ha trabajado, una vez pasada la poca de tubos de vaco, con componentes (cpsulas) en los que se integran otros muchos componentes. Sus principales avances han sido tecnolgicos: cada vez caben ms componentes por unidad de superficie, pero siempre ha estado presente implcitamente un concepto primordial, la reutilizacin. Resultara inaceptable que se estropeara un componente electrnico y que hubiera que construir otro idntico desde cero; o que los nuevos componentes tuvieran necesariamente que desarrollarse combinando resistencias, condensadores y bobinas, sin poder aprovechar nada de todos los componentes ya fabricados; o que fuera imprescindible conocer todos los elementos de un componente antes de poder saber para qu podra servir. Antes de que los conceptos de modularidad y encapsulacin tuvieran la importancia capital que tienen hoy en la ingeniera del software (hasta mediados de la dcada de 1960 no se empez a hacer un uso intensivo de la modularidad), en la programacin suceda lo que era inaceptable en la electrnica. A saber: que empezar un nuevo programa era, a menudo, comenzar desde cero y que la reutilizacin de componentes de programacin era mnima. En los pocos casos en que se podan reutilizar esos componentes, se necesitaba conocer cmo funcionaban por dentro, lo que tornaba imposible la encapsulacin. Haba, en fin, ms artesana del software que ingeniera del software.
4.4 Jerarqua
Segn el Dictionary of OT, la jerarqua es Cualquier clasificacin u ordenacin de abstracciones en una estructura de rbol. Tipos: Jerarqua de agregacin, jerarqua de clases, jerarqua de herencia, jerarqua de particin, jerarqua de especializacin, jerarqua de tipo. Las jerarquas se han utilizado desde hace mucho tiempo en las ciencias naturales para clasificar a los seres vivos. Con ello no quiero decir que los primeros botnicos o zologos pudieran ser, de haber vivido en esta poca, unos extraordinarios programadores; sino que entendieron desde el principio la importancia de dividir los problemas en una jerarqua de ideas. Quizs Aristteles fuera un poco desencaminado en cuanto a los detalles (vase el apdo. 3.1), pero andaba bastante acertado en cuanto a las ideas generales. Los dos tipos de jerarqua ms comunes son la jerarqua de generalizacin/especializacin (Una nevera es un electrodomstico) y la de todo/parte (Una mesa se compone de cuatro patas y una superficie).
Ser vivo Animal Mamfero Persona Trabajador Programador

Figura 15. Un ejemplo de jerarqua del tipo generalizacin/especializacin. Por ejemplo, toda persona es un mamfero, pero no todo mamfero es una persona.
Pgina 45 de 55
La jerarqua de generalizacin/especializacin se basa en que las propiedades de una categora general se transmiten a todas las categoras que la especializan. Se suele aludir a esta jerarqua con la regla es un o es un tipo de, pues una categora especializa a otra si es un tipo de la segunda. En la OO, el trmino jerarqua de clases significa un conjunto de clases relacionados por la jerarqua de generalizacin/especializacin. En una jerarqua, una clase puede ser una especializacin (subclase o clase hija) de otra (superclase o clase madre) cuando representa, con respecto a la superclase, un elemento ms especfico en el dominio modelado. Las subclases heredan los atributos o propiedades descritos en su superclase. En los sistemas de software, la jerarqua de generalizacin/especializacin suele implementarse mediante la herencia. Este trmino designa la facultad que tienen algunos lenguajes OO no todos: vase la segunda parte del tutorial de formar nuevas clases usando clases ya existentes, donde las nuevas clases toman de la nueva clase su implementacin y sus caractersticas. Las clases derivadas o subclases heredan o extienden los atributos y mtodos de su superclase, sin tener que volver a implementar los mtodos. Muy relacionado con la herencia se encuentra el polimorfismo. Aunque se trata con detalle en la 2 parte del tutorial, adelanto aqu que el polimorfismo permite sobrescribir en las subclases los mtodos de la superclase. A diferencia de lo que ocurre en los lenguajes estructurados, los lenguajes OO permiten que el mtodo con que se responde a un mensaje dependa del objeto concreto al que se enva el mensaje. Por ejemplo, consideremos una subclase CuentaMancomunada que reescribe el mtodo sacarDinero() de una superclase CuentaBancaria. Cuando un objeto CuentaBancaria reciba un mensaje sacarDinero() transferir el dinero; cuando un objeto CuentaMancomunada reciba ese mismo mensaje, antes de transferirlo comprobar que la operacin est solicitada por todos los titulares de la cuenta, y si no es as anular la operacin y enviar un mensaje de que no ha podido atender la peticin. En ambos casos se enva el mismo mensaje (la peticin es la misma), pero el comportamiento final depende del objeto que lo recibe. En un programa, una misma variable puede representar, conforme se va ejecutando el programa, distintos tipos de objetos. Por tanto, tambin puede llamarse a distintos mtodos de la variable durante el tiempo de ejecucin. Como se vio en 3.3, la metodologa estructurada se basa en la abstraccin por descomposicin. La OO incluye tambin la descomposicin como un mecanismo de abstraccin, pero la complementa con la herencia, que se basa en la abstraccin por clasificacin. En mi opinin, la abstraccin por clasificacin no tiene equivalente en la metodologa estructurada y constituye, por tanto, una caracterstica novedosa de la OO. A fecha de hoy, el debate de la evolucin-revolucin de la OO frente a la metodologa contina abierto. La herencia es responsable, combinada con la modularidad, del xito de la OO, por cuanto permite la reutilizacin del cdigo OO. La correcta utilizacin de la herencia y la modularidad permite concebir los programas OO como una unin de cpsulas intercambiables con otros programas, que pueden transmitir sus propiedades (atributos y mtodos) a nuevas capsulas sin tener que desarrollarlas desde cero. En los sistemas de software el mantenimiento ha supuesto siempre un coste muy grande. La herencia y la modularidad permiten reducir el coste de las modificaciones, casi siempre inevitables, que deben ir sufriendo los programas segn se van mellando por el contacto con la realidad.
5. Lenguajes de programacin orientados a objetos. Puede utilizarse la OO en lenguajes no orientados a objetos?

Por lo general, la OO se relaciona con el uso de lenguajes de programacin orientados a objetos. Como metodologa general de desarrollo de sistemas, la OO es independiente de cualquier lenguaje, sea orientado a objetos o no. El anlisis y diseo OO puede aplicarse para construir cualquier sistema, independientemente de que se implemente al final en un lenguaje OO o no. En cuanto a la POO, es posible incluso en lenguajes no orientados a objetos. No existe un acuerdo comn e inapelable en la bibliografa sobre los requisitos que debe cumplir un lenguaje para considerarse OO, pero generalmente se admite que un lenguaje OO debe tener como mnimo: a) Encapsulacin b) Herencia c) Polimorfismo Adicionalmente, en un lenguaje OO puede suceder que d) todos los tipos de datos predefinidos en el lenguaje sean objetos; e) todos los tipos de datos que puedan ser definidos por los programadores sean objetos; f) todas las posibles operaciones se realicen enviando mensajes entre objetos. Se consideran lenguajes OO puros aquellos que tienen las 6 caractersticas a)-f) y se consideran hbridos aquellos que carecen de alguna de las 3 ltimas: d), e) f). En http://www.javahispano.org/portada/2011/8/1/orientacion-a-objetos-ii.html se encuentra la segunda parte de este trabajo, donde se analizan los lenguajes OO ms conocidos y se explican en detalle la herencia y el polimorfismo.
Caracterstica a) b) c) d) e) f)
Fortran 77 NO NO NO NO NO NO
C++ SI SI SI NO NO NO
C# SI SI SI NO NO NO
Java SI SI SI NO SI NO
Smalltalk SI SI SI SI SI SI
Eiffel SI SI SI SI SI SI
Tabla 4. Ejemplos de lenguajes no OO, OO hbridos y OO puros.
Como ya he mencionado, se puede escribir programas OO en lenguajes no OO. Para conseguirlo, el programador debera implementar las principales caractersticas de la OO en el lenguaje seleccionado (convertir en objetos las estructuras de datos propia del lenguaje no OO, almacenarlos en memoria, elegir cuidadosamente los nombres de los mtodos para asociarlos inmediatamente a los objetos correspondientes, implementar manualmente la herencia y el polimorfismo...); proceso innecesario en un lenguaje OO, pues ya posee de partida esas implementaciones.
En la prctica, siempre ser ms rpido y eficaz trabajar directamente con lenguajes OO que implementar las caractersticas OO en lenguajes no orientados a objetos. Como ejemplo de las dificultades de usar los conceptos de la OO en lenguajes no OO, implemento aqu, en Fortran 77 y C, una clase Rectangulo (omito las tildes para los nombres de las clases) y la herencia para dos clases Circulo y Elipse que derivan de una clase Punto. En la segunda parte del tutorial se explican cmo se implementan los conceptos de la OO en los lenguajes OO ms conocidos. Implementacin de la clase Rectngulo en Fortran 77 implicit none common /rectangulo/ x1, x2, y1, y2, num_rectangulo real x1(100), x2(100), y1(100), y2(100) integer num_rectangulo Este cdigo define una clase Rectangulo, en la que cada rectngulo se caracteriza por las coordenadas de sus vrtices. Guarda en memoria simultneamente 100 objetos de tipo rectngulo (en Fortran 77 no existe la asignacin dinmica de memoria) y el ndice entero num_rectangulo identifica en todo momento cualquier objeto rectngulo. El bloque common permite que ciertas variables se comportan entre varias subrutinas. En Fortran 77 un objeto solo puede representarse por una coleccin de cadenas de variables, en la que cada variable un atributo del objeto. No existen tipos de datos definidos por el usuario.
Implementacin de la clase Rectangulo en C struct rectangulo{ float x1; float x2; float y1; float y2; } Para iniciar un objeto rectngulo se usara algo as: struct rectangulo miRectangulo={0, 2, 3, 5}
Pgina 48 de 55
Implementacin de la herencia en Fortran 77 con las clases Elipse y Circulo, que derivan de la clase Punto Implementacin de las clases Elipse y Circulo. implicit none common /figura/ x, y, semiejea, semiejeb, radio, num_figura, clase_figura real x(100), y(100), semiejea(100), semiejeb(100), radio(100) integer num_figura integer clase_figura(100) common /clases/ ELIPSE, CIRCULO integer ELIPSE /1/, CIRCULO /2/ Este modo de implementar la herencia resulta muy ineficaz, pues reserva espacio en memoria tanto para los atributos de la clase base Punto (coordenadas x e y) como para los atributos adicionales de las clases derivadas Circulo (radio) y Elipse (semiejes). Para crear objetos derivados o hijos, el cdigo sera similar a ste: function crear_elipse(x0, y0, semiejea0, semiejeb0) common /figura/ x, y, semiejea, semiejeb, radio, num_figura, clase_figura real x(100), y(100), semiejea(100), semiejeb(100), radio(100) integer num_figura integer clase_figura(100) common /clases/ ELIPSE, CIRCULO integer ELIPSE /1/, CIRCULO /2/ integer crear_elipse num_figura=num_figura + 1 x(num_figura)=x0 y(num_figura)=y0 semiejea(num_figura)=semiejea0 semiejeb(num_figura)=semiejeb0 radio(num_figura)=0 clase_figura(num_figura)=ELIPSE crear_elipse=num_figura end function crear_circulo(x0, y0, radio0) common /figura/ x, y, semiejea, semiejeb, radio, num_figura, clase_figura real x(100), y(100), semiejea(100), semiejeb(100), radio(100) integer num_figura integer clase_figura(100)
Pgina 49 de 55
common /clases/ ELIPSE, CIRCULO integer ELIPSE /1/, CIRCULO /2/ integer crear_circulo num_figura=num_figura + 1 x(num_figura)=x0 y(num_figura)=y0 semiejea(num_figura)=radio0 semiejeb(num_figura)=radio0 radio(num_figura)=radio0 clase_figura(num_figura)=CIRCULO crear_circulo=num_figura end
Para implementar el polimorfismo bastara comprobar, dado un objeto (caracterizado por su num_figura), cul es el valor de clase_figura(num_figura) y, dependiendo de si es CIRCULO o ELIPSE, asignarle un mtodo u otro. Implementacin de la herencia en C con las clases Elipse y Circulo, que derivan de la clase Punto struct punto{ float x; float y; }; struct circulo{ struct punto origen_figura; float radio; }; struct elipse{ struct punto origen_figura; float semiejea; float semiejeb; };
He escogido calculadamente Fortran 77 para los ejemplos porque es un lenguaje primitivo pero extremadamente potente para aplicaciones que requieran clculos numricos intensivos si lo comparamos con los lenguajes de programacin actuales. Fortran es el equivalente informtico de un mamut lanudo que hubiera escapado de una glaciacin y perviviera en nuestros das. Para ser justo, aado que la versin anterior (Fortran 66) se utilizaba con tarjetas perforadas y que las versiones actuales (Fortran 90 y 95) incorporan asignacin dinmica de la memoria y punteros, tipos de datos definidos por el usuario, mdulos en el sentido de la OO y otras caractersticas. Por ser un lenguaje que tiene un nico tipo de estructuras de datos (matrices) resulta posible, pero muy complicado e ineficaz, implementar los principios de la OO.
En C resulta mucho ms fcil implementar la herencia, porque permite al programador definir sus propias estructuras de datos, y el uso de la asignacin dinmica de la memoria hace que se aproveche mucho ms eficazmente la memoria que en Fortran 77. En resumen, debemos extraer dos lecciones de este apartado. Por un lado, que el anlisis y diseo OO se puede emplear siempre, aunque la implementacin final se haga en un lenguaje no OO. Por otro, que es posible escribir programas OO con lenguajes no OO, si bien uno debe encontrarse verdaderamente desesperado para desaprovechar las ventajas que brindan los lenguajes OO.
Pgina 51 de 55
6. l xito del paradigma orientado a objetos

6.1 l xito del paradigma orientado a objetos, se basa nicamente en criterios objetivos?
Una vez expuestos los fundamentos de la OO, y antes de definir detenidamente sus conceptos, es interesante reflexionar sobre el xito de la OO desde una perspectiva poco ortodoxa y un tanto hertica. En su clebre libro La estructura de la revoluciones cientficas (publicado en 1962, la primera edicin en espaol data de 1971), Thomas S. Kuhn defini paradigma en el sentido de matriz disciplinaria: elementos ordenados de diversas maneras, cuyo orden hay que especificar, que son posesin comn de los profesionales de una disciplina. Cuando se dice que un grupo de cientficos comparten un mismo paradigma, se est diciendo que comparten una manera de ver el mundo y practicar la ciencia en l. Kuhn propona que cuando los cientficos observan determinados fenmenos no los miran objetivamente, sino a travs del filtro de un conjunto de ideas y conceptos (procedentes de la tradicin cultural, social y cientfica en la que han sido educados) que han formado/deformado su percepcin. En otras palabra, los ven a travs de un paradigma firmemente establecido. Solo as poda entenderse pensaba Kuhn que ideas como que la velocidad de cada de los cuerpos era proporcional a su masa hubieran pervivido desde la Grecia antigua hasta Galileo Galilei, cuando unos sencillos experimentos hubieran demostrado, ms all de toda duda razonable, su falsedad. Si creemos a Kuhn, los cientficos de todos esos siglos intermedios aceptaron la idea de que los cuerpos caan con una velocidad proporcional a su masa como parte de su cultura (y de su paradigma), y por ello no se plantearon hacer experimentos ni vieron los hechos que iban contra esa idea. Del mismo modo, los primeros que miraban a travs del telescopio de Galileo no vean ms que manchas y sombras porque an no haban asimilado el nuevo paradigma astronmico. Donde Galileo vea cuerpos celestes, los otros vean manchas sin sentido o ilusiones pticas, que atribuan al propio aparato. Muchos siglos despus, todava entristecen las frases con las que Galileo tuvo que cerrar su nuevo paradigma astronmico, que sobrevivi a los inquisidores y sigue vigente:
Yo, Galileo, hijo del difunto Vicenzo Galilei, florentino, de setenta aos de edad, emplazado en persona ante este tribunal y arrodillado ante vos, eminentsimo y reverendsimo Cardenal Inquisidor General contra la depravacin hertica en el orbe cristiano, teniendo ante mis ojos y tocando con mis manos los Santos Evangelios, juro que siempre he credo, creo y creer, con la ayuda de Dios, todo lo que es sostenido, predicado y enseado por la Santa Iglesia Catlica y Apostlica. Tras la prohibicin que me ha sido impuesta judicialmente por este Santo Oficio al efecto de que yo abandone completamente la falsa opinin de que el Sol es el centro del mundo, y est inmvil, y que la Tierra no es el centro del mundo, y se mueve, y de que no debo sostener, defender o ensear dicha falsa doctrina de ninguna de las maneras, ni verbalmente ni por escrito..." (Frmula de abjuracin de Galileo Galilei, 22 de junio de 1633).
Segn Kuhn, cuando un cientfico o un grupo de cientficos se coloca las gafas de un nuevo paradigma, el resto de la comunidad cientfica reniega y manifiesta su desacuerdo hasta que el paradigma emergente demuestra su validez (mediante hechos empricos o nuevas lneas de investigacin); o hasta que los viejos cientficos, educados en el paradigma anterior, fallecen de viejos. Al cabo de una o dos generaciones, todos
los cientficos se educan ya en el nuevo paradigma, y los conflictos conceptuales entre el paradigma antiguo y el nuevo son solamente recordados por filsofos o historiadores de la ciencia que mantienen encarnizadas batallas dialcticas sobre la respectiva superioridad o inferioridad de cada paradigma. Y as sucede una y otra vez. En resumen, Kuhn vena a decir que hay un componente sociolgico y cultural, ajeno a la pretendida ciega objetividad cientfica, en el modo en que los cientficos de una poca observan el mundo y que los paradigmas son consensos tcitos dentro de una comunidad (cientfica, tcnica, etc.). La orientacin a objetos es el paradigma aceptado actualmente para construir sistemas de software y ha relevado al antiguo paradigma estructurado (dicho con la jerga de Kuhn, es el paradigma dominante). Denominar paradigma a la OO (o la metodologa estructurada) no es una exageracin o una libertad que me tomo: la OO es un paradigma porque ha cambiado el modo en que los ingenieros de software y los desarrolladores piensan sobre el software. La OO es el paradigma dominante: los estudiantes de ingeniera del software se forman ya en la OO, est incluida en los planes acadmicos y sus trminos son de uso comn. Mas an: los lenguajes OO (Java, sobre todo) han desplazado a los lenguajes estructurados tradicionales que se utilizaban en las asignaturas de introduccin a la programacin (Pascal, C). Por qu se ha impuesto como paradigma la orientacin a objetos? En gran parte por su efectividad: el desarrollo de gigantescos programas de software volvi inservible el paradigma estructurado, y la OO permite abordar viejos problemas de nuevas maneras y con costes menores. Sin el nuevo paradigma, muchos proyectos modernos no se habran ejecutado. Tambin se ha impuesto por su sencillez conceptual (quin no sabe lo que es un objeto?, cuntos de nosotros pensamos con algoritmos?): la OO est mucho ms cercana al pensamiento humano que el paradigma estructurado. Con todo, no cabe cegarse ante la evidencia: hay un cierto elemento de profeca autocumplida en el xito de la OO. Supngase que los investigadores de prestigiosas universidades comenzasen a desarrollar lenguajes MM, crearan revistas y publicaciones con las siglas MM engordando de paso sus currculos- y abrieran nuevas parcelas de investigacin con nuevas promesas de sencillez, productividad, ahorro de costes, etc. Las empresas se haran eco de estas promesas (aunque solo sea por miedo a que otras empresas usen las nuevas tcnicas antes que ellas) y la industria apoyara el nuevo paradigma; apareceran libros, tcnicos y del tipo Aprenda MM en 21 das, comits de normalizacin, becas para investigar la MM; y las empresas anunciaran orgullosas sus inversiones en MM, presentndose probablemente como empresas en el filo de la tecnologa. Acaso no sera difcil que el nuevo paradigma, avalado y apoyado por la industria y la comunidad investigadora, fracasara? Es probable que a base de esfuerzo e inversiones se consiguieran xitos totales o parciales- que reafirmaran las promesas iniciales de sencillez, productividad, etc. Cuesta mucho sustituir MM por OO? El xito de la OO, como el xito de muchas teoras cientficas, tiene un pequeo componente sociolgico y comunitario. Difcilmente se embarcara hoy alguien en un importante proyecto de software sin seguir la metodologa OO, porque es el paradigma dominante y resulta muy difcil conseguir financiacin para ideas o proyectos fuera del paradigma dominante. Y lo que es peor: nadie quiere fracasar a contracorriente; se prefiere fracasar siguiendo las ideas aceptadas que triunfar siguiendo ideas novedosas. Ya sabe, es mejor morir segn las reglas que salvarse a ltima hora en contra de ellas. Que se lo digan a los Rolling Stones.
Pgina 53 de 55
6.2 Los lmites de la POO

Aunque constituye el paradigma dominante en el campo de la programacin, la programacin orientada a objetos no aporta capacidades o mtodos de resolucin de problemas irresolubles en sentido terico por otros medios o tcnicas. Una mquina de Turing podra ser simulada por cualquier lenguaje de programacin que permitiera sentencias condicionales y saltos. De acuerdo con la conjetura de Church, cualquier computacin para la que exista un algoritmo funcional (ya fuera el tiempo necesario de computo finito o no) podra ser realizada por una mquina de Turing. Por lo tanto, cualquier computacin con un algoritmo funcional puede realizarse en cualquier lenguaje de programacin que permita sentencias condicionales y saltos, sea o no un lenguaje OO. Uso realizarse en un sentido terico; en la prctica hay limitaciones de tiempo, memoria, coste... La OO suministra unos nuevos anteojos conceptuales a travs de los cuales ver el mundo y comprender y solucionar los problemas de un modo ms rpido, eficaz, econmico y natural que con el paradigma estructurado. Ahora bien, su aplicacin a la programacin no resuelve problemas insolubles con otros medios o tcnicas.
Pgina 54 de 55
Sobre el autor: Miguel ngel Abin naci en Soria. Obtuvo la suficiencia investigadora en el Dpto. de Fsica Aplicada de la Universidad de Valencia con una tesina sobre electromagnetismo. Realiz varios cursos de doctorado relacionados con electromagnetismo, electrnica, semiconductores y cristales fotnicos. Ha recibido becas del IMPIVA (Instituto de la Mediana y Pequea Industria Valenciana) y de la Universidad Politcnica de Valencia. Curs un Mster estadounidense en UML y Java y otro sobre tecnologas de Internet/Intranet. Se incorpor en 1998 a AIDIMA, donde ha participado como investigador en 23 proyectos de investigacin nacionales e internacionales relacionados con la Web semntica, tecnologas de la informacin, madera en construccin, biosensrica, bioelectrnica, telecomunicaciones, visin artificial; as como en la Red de Excelencia de la Comisin Europea INTEROP 2003-2007. Algunos de los proyectos europeos relacionados con las tecnologas semnticas en los que ha participado son ATHENA y STASIS (http://www.stasisproject.net/). El ao 2006 estuvo cuatro meses como investigador invitado en el departamento Lehrstuhl fr Messsystem und Sensortechnik de la Universidad Politcnica de Munich (TUM), donde colabor en el desarrollo de nuevos mtodos para la deteccin de defectos en superficies acabadas y en el diseo e implementacin de sistemas distribuidos de sensores para el sector del automvil y de energas renovables. En 2007 recibi un premio BANCAJAUPV por un proyecto relacionado con la calidad interna de la madera. En 2009 recibi el premio internacional Schweighofer Innovation Prize -el premio ms prestigioso en el sector forestal y de la madera- por su aportacin al desarrollo de nuevas tecnologas de evaluacin no destructiva de la madera en construccin. Actualmente es Responsable del Departamento de Tecnologa y Biotecnologa de la Madera y del rea de Construccin de Madera. Es coautor de 7 libros y guas tcnicas relacionadas con el uso de la madera en la construccin y la visin artificial. Tambin ha publicado varios artculos cientficos en revistas como IEEE Transactions on Microwave Theory and Techniques y Wood Science and Technology. Ha participado como ponente en congresos y conferencias como European Congress on Computational Methods in Applied Sciences and Engineering, IEEE International Conference on Multisensor Fusion and Integration for Intelligent Systems, International Conference on Space Structures (IABSE-IASS) y en reuniones COST (European Cooperation in Science and Technology). Ha publicado ms de 22 artculos tcnicos en revistas sectoriales y tcnicas. Es autor o coautor de 6 patentes, algunas de ellas en trmite. Tres de ellas corresponden a dispositivos y mtodos para detectar la biodegradacin de la madera en construccin. Actualmente, entre otros proyectos como WOODRUB o CELLUWOOD, trabaja en SEMCONCEPT, un proyecto de I+D+i para aplicar tecnologas semnticas (ontologas, buscadores semnticos) en el diseo conceptual de productos industriales. Sus intereses actuales son la evolucin de la programacin orientada a objetos, Java, la Web semntica y sus tecnologas, la arquitectura orgnica, el surrealismo y Pars, siempre Pars.
Pgina 55 de 55

Programacion Orientada A Objetos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Programacion Orientada A Objetos

Transféré par

Droits d'auteur :

Formats disponibles

ORIENTACIN A OBJETOS: CONCEPTOS, TERMINOLOGA Y LENGUAJES (PARTE 1)

Versin 3.0 (2012) Miguel ngel Abin

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

ORIENTACIN A OBJETOS: CONCEPTOS, TERMINOLOGA Y LENGUAJES (PARTE 1)

Learning Analysis, Oriented Software

Miguel ngel Abin, 2002-2012

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

ORIENTACIN A OBJETOS: CONCEPTOS, TERMINOLOGA Y LENGUAJES (PARTE 1)

Miguel ngel Abin, 2002-2012

1. Introduccin. El porqu de este trabajo

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

2. Glosario de la orientacin a objetos

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

Miguel ngel Abin, 2002-2012

Mundo real Cosa Concepto, idea, abstraccin Interaccin

Orientacin a objetos Objeto Clase Operacin

arranca hojas anota enciende apaga

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

arranca hojas 1 anota Empleado

Ordenador enciende apaga 1

Miguel ngel Abin, enero 2006

Miguel ngel Abin, 2002-2012

Miguel ngel Abin, enero 2006

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

<<object>> joseLuis: Empleado <<class>> Empleado

<<object>> cpidd: Empleado

Miguel ngel Abin, enero 2006

Miguel ngel Abin, 2002-2012

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

3. Visin general de la orientacin a objetos

3.2 La orientacin a objetos como metodologa de desarrollo de sistemas.

public void aterrizar{...} public void despegar{...} }

Miguel ngel Abin, enero 2006

Figura 6. Las tres etapas de la OO (aplicada a sistemas de software).

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

Figura 7. En ingeniera del software, el proceso de anlisis corresponde a esta figura.

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

MODELO DE DOMINIO DE LA BIBLIOTECA

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

La aplicacin se programar en un lenguaje OO. Los datos se guardarn en Oracle.

Miguel ngel Abin, 2002-2012

El primer punto corresponde al modelo esttico; el segundo, al dinmico.

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0

Miguel ngel Abin, 2002-2012

Miguel ngel Abin, 2002-2012

Orientacin a objetos: conceptos, terminologa y lenguajes (Parte 1) v3.0