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

ORIENTACIN A OBJETOS: CONCEPTOS, TERMINOLOGA Y LENGUAJES (PARTE 1)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

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


ORIENTACIN A OBJETOS: CONCEPTOS, TERMINOLOGA Y LENGUAJES (PARTE 1)Miguel ngel AbinFecha de creacin: 23.04.2012 Versin: 3.0Copyright (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 trabajoEl 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. Miguel ngel Abin, 2002-2012 Pgina 7 de 55


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 Miguel ngel Abin, 2002-2012 Pgina 8 de 55


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 objetosEn 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 Miguel ngel Abin, 2002-2012 Pgina 11 de 55


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 DomingoMiguel 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 EmpleadoNombre Apellidos

AgendaPrecio

1

Ordenador enciende apaga 1Fabricante Velocidad Memoria

Miguel ngel Abin, enero 2006

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 Empleadonombre: String apellidos: String fichar(fecha: Date) trabajar() tomarCafe() precio: double anotar(texto: String) arrancarHoja()

1

Ordenador 1fabricante: 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


joseLuis: Empleado Empleadonombre: String apellidos: String fichar(fecha: Date) trabajar() tomarCafe() nombre: Jos Luis apellidos: Ferreira

mperez: Empleadonombre: Manolo apellidos: Prez

cpidd: Empleadonombre: 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 objetos3.1 Orgenes de los conceptos de la OOPese 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 Miguel ngel Abin, 2002-2012 Pgina 18 de 55


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 COMPLETOAnlisis OO Diseo OO Avion- modelo: String - codigo: String aterrizar() despegar()

Programacin OOpublic 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. Miguel ngel Abin, 2002-2012 Pgina 20 de 55


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.

ANLISISClientes

DominioProblema Usuarios Entrevistas con expertos en el dominio Anlisis OO Conocimiento del mundo realMiguel ngel Abin, enero 2006

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. Miguel ngel Abin, 2002-2012 Pgina 22 de 55


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. Miguel ngel Abin, 2002-2012 Pgina 24 de 55


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 BIBLIOTECATrabajadorBiblioteca 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.. 1Miguel ngel Abin, enero 2006

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. Miguel ngel Abin, 2002-2012 Pgina 26 de 55


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 CRCNombre de la clase: SocioBiblioteca Responsabilidades: Almacena los datos personales del socio Almacena la informacin sobre los prstamos en vigor Almacena informacin sobre sanciones Colaboradores: EjemplarMiguel ngel Abin, enero 2006

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 BIBLIOTECAbibliotecario :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 estructuradaAntes 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. Miguel ngel Abin, 2002-2012 Pgina 35 de 55


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 objetosObjeto 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 pruebasmodule A

Modelo de anlisis OOmodule B

module C

module D module E

b f a d

c

e

Diseo OO

Modelo de diseo OO

Programacin OOMiguel ngel Abin, enero 2006

(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. Miguel ngel Abin, 2002-2012 Pgina 39 de 55


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 quea 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 objetosLa orientacin a objetos se fundamenta en los siguientes principios: Abstraccin Modularidad Encapsulacin Jerarqua

4.1 AbstraccinLa 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

programacion orientada a objetos

Documents