Instituto Tecnolgico de Minatitln

Estado del Arte de los Conceptos Bsicos del Modelo Orientado a Objetos Alumno: HERNANDEZ GUTIERREZ FAUSTO

Especialidad: ING. EN SISTEMAS COMPUTACIONALES

Materia: FUNDAMENTOS DE PROGRAMACION

Catedrtico: ING. JOS NGEL TOLEDO LVAREZ

UNIDAD 1: CONCEPTOS BSICOS DEL MODELO ORIENTADO A OBJETOS

Los conceptos fundamentales del diseo y la programacin orientada a objetos han sido desarrollados hace ms de treinta aos, pero en los ltimos diez ha tenido un crecimiento vertiginoso en la industria de desarrollo de software, merced a los progresos en velocidad y capacidad de procesamiento, junto con la necesidad de creacin de software de alta complejidad. A la luz de los pasos del hombre en sus mtodos para la construccin del conocimiento, encontramos que la programacin ha recorrido en los sesenta aos de su existencia un camino similar. Sospecho, sin embargo, que no era muy capaz de pensar. Pensar es olvidar diferencias, es generalizar, abstraer. Funes, el memorioso, Jorge Luis Borges En los ltimos treinta aos, la informtica ha realizado avances notables con respecto al hardware, las comunicaciones y las capacidades multimediales de las computadoras. Sin embargo, en el plano del desarrollo de sistemas complejos salvo contadas excepciones las herramientas elaboradas no usan las capacidades de simulacin y emulacin que convierten una computadora en un laboratorio virtual de infinitas posibilidades de creacin. A fines de la dcada del 60, Alan Kay cre la Dynabook, convencido de que la simulacin es una herramienta notable para la comunicacin de ideas y que una computadora debera ser el contenedor de todos los medios de expresin en los que uno pudiera pensar, es decir, un meta-medio. La Dynabook deba de ser un dispositivo porttil, con red inalmbrica y pantalla plana, entre otras cosas. Este dispositivo funcionara como un "amplificador de la mente" y como lugar donde un usuario concentrara toda la informacin que consume y que genera. En un contexto en el que las computadoras eran grandes mquinas de costo altsimo, de uso privativo de grandes corporaciones, pensar en una computadora personal con estas caractersticas era dar un enorme salto hacia el futuro. Guiados por esta visin, un grupo de referentes de la informtica (Alan Kay, Dan Ingalls, Adele Goldberg, etc.) crean Smalltalk, un ambiente de objetos de donde surgen "la mayora de las cosas buenas relacionadas con las computadoras personales (incluido el propio nombre)"1. Una lista, no completa, de los aportes de este proyecto al desarrollo de la informtica son:

El concepto de la Computadora Personal El paradigma de objetos Smalltalk Interfaces de usuario grficas Uso del mouse Drag & drop (Arrastrar y arrojar) Menes despegables

Curiosamente, el proyecto y la filosofa Smalltalk surgieron con la misma idea: crear un entorno en el cual el proceso de simulacin en una computadora fuera equivalente al proceso de pensamiento, de comprensin, de modelizacin humana. Si, finalmente, el aprendizaje no es ms que una modelizacin mental acotada de un Universo infinitamente

complejo y caprichoso, la computadora tena que presentar un ambiente similar para poder utilizarla como un laboratorio virtual altamente manipulable. Es decir, entendemos al proceso de construccin de software como un proceso de modelizacin anlogo al proceso que realiza un cientfico al tomar un espacio acotado del universo en el que vivimos, en un conjunto acotado de objetos y propiedades, que permita encontrar un modelo que luego pueda ser aplicado no slo al conjunto de datos que utiliz para su estudio, sino tambin a otros casos posteriores que se encuentren dentro de la cota de su estudio. En el proyecto Smalltalk aparecen conceptos que hoy en da estn presentes en todos los ambientes de creacin de software: objetos, atributos, clases, mensajes y mtodos. Objetos, como aquellos elementos que entran en juego en el sistema que estoy modelando (por favor, pensar en sistemas como algo ms amplio que un programa en una computadora). Atributos, como las caractersticas que me interesa representar de cada objeto para el recorte que hago del universo. Clases, como el agrupamiento de objetos con caractersticas y comportamientos comunes. Mensajes, como la forma de comunicarse y de solicitar colaboracin que tienen los objetos entre s. Y mtodos, como la descripcin de la respuesta de un objeto a un determinado mensaje. Volviendo al concepto de clases, cuando el diseador se encuentra con un conjunto de objetos que comparten los mismos atributos y el mismo comportamiento (por ejemplo, cada uno de los empleados de una empresa donde se est construyendo un sistema de jornales; cada uno de los productos que produce una fbrica donde se est realizando un sistema de control de stock), utiliza el mecanismo de clasificacin para abstraer estas propiedades y comportamiento. De esta forma, la construccin de la clase le permite generar una suerte de plantilla a partir de la cual puede construir los objetos que forman parte del sistema. Esta plantilla es un modelo recortado que toma nicamente las propiedades y comportamiento que le interesan para el sistema que est modelando en ese momento. En el proceso de clasificacin nos encontramos frecuentemente con clases que comparten algunas caractersticas comunes. Por este motivo, en los ambientes de objetos podemos construir clases superiores o abstractas, que encapsulan el comportamiento comn, para que el conjunto de clases con caractersticas comunes hereden de la clase abstracta dichas propiedades. Al mecanismo por el cual una clase recibe comportamiento y propiedades de una clase superior, se le llama Herencia. Por ejemplo, en el caso de la clasificacin de los vertebrados, podemos encontrarnos con la clase Mamferos. Todas las subclases de Mamferos heredan las propiedades y el comportamiento que le corresponde a los objetos que pertenecen a la clase Mamferos. Por lo tanto, los Carnvoros, los Roedores, los Primates, por nombrar algunas de las subclases de Mamferos, heredan la propiedad de tener mamas, de tener sangre caliente, etc. A su vez, la clase Carnvoro tiene la subclase Perro, la cual hereda los atributos tanto de Carnvoro como de Mamfero. Es decir, cada subclase es una especializacin de la clase superior. Habitualmente, en el diseo frecuente de modelos similares, comenzamos a encontrar estructuras de clases anlogas entre los diferentes modelos. A partir del ejercicio de diseo, podemos desarrollar un conjunto de clases vinculadas entre s, que con pequeas modificaciones, nos permitan desarrollar soluciones para problemas en mbitos similares. A esta estructura de clases se la denomina Framework. Slo el diseo reiterado de modelos similares nos permite encontrar este tipo de estructuras. Por ejemplo, si un

desarrollador realiza un modelo del tateti, del ajedrez, del sokoban, del teg, probablemente encuentre un nivel de abstraccin superior, los juegos de tablero, que le permita construir un conjunto de clases que con una pequea adaptacin permita disear cualquier juego de tablero. Ha encontrado un framework para juegos de tablero. Existen frameworks para sistemas contables, para sistemas de control de produccin, para reglas de negocios, etc. Yendo a un nivel de abstraccin ms alto an, en todos los desarrollos de sistemas hay un conjunto de problemas que se presentan en forma sistemtica. Luego de aos de trabajo, los desarrolladores han encontrado estructuras de clases que permiten presentar una solucin efectiva, econmica y probada para estos problemas. A estas soluciones se las denomina Patrones de diseo. Habiendo presentado (en forma harto resumida) los conceptos fundamentales del diseo orientado a objetos, podremos mostrar donde encontramos los mtodos de inferencia tradicionales de la ciencia en el proceso de construccin del software.

1.1 RECONOCIMIENTO DE OBJETOS Y CLASES EN EL MUNDO REAL Y LA INTERACCIN ENTRE ELLOS.

La capacidad de reconocer objetos fsicos es una habilidad que los humanos aprenden en edades muy tempranas. Una pelota de colores llamativos atraer la atencin de un nio, pero casi siempre, si se esconde la pelota, el nio no intentar buscarla; cuando el objeto abandona su campo de visin, hasta donde l puede determinar, la pelota ha dejado de existir. Normalmente, hasta la edad de un ao un nio no desarrolla lo que se denomina el concepto de objeto, una habilidad de importancia crtica para el desarrollo cognitivo futuro. Mustrese una pelota a un nio de un ao y escndase a continuacin, y normalmente la buscar incluso si no esta visible. Atravs del concepto de objeto, un nio llega a darse cuenta de que los objetos tienen una permanencia e identidad adems de cualesquiera operaciones sobre ellos. Informalmente podemos entender un objeto como una entidad tangible que exhibe algn comportamiento bien definido. Desde la perspectiva de la cognicin humana, un objeto es cualquiera de las siguientes cosas: Una cosa tangible y/o visible Algo que no puede comprenderse intelectualmente Algo hacia lo que se dirige un pensamiento o accin Se aade a la definicin informal la idea de que un objeto modela alguna parte de la realidad y es, por lo tanto, algo que existe en el tiempo y el espacio. En software, el trmino objeto se aplic formalmente en primer lugar en el lenguaje Simula; los objetos existan en los programas en Simula tpicamente para simular algn aspecto de la realidad. Los objetos del mundo real no son el nico tipo de objeto de inters en el desarrollo del software. Otros tipos importantes de objetos son invenciones del proceso de diseo cuyas elaboraciones con otros objetos semejantes sirven como mecanismos para desempear algn comportamiento de nivel superior. Esto nos lleva a la definicin ms refinada de Smith y Jockey, que sugieren que un objeto representa un elemento, unidad o entidad individual e identificable, ya sea real abstracta, con un papel bien definido en el dominio

del problema. En trminos an ms generales, se define un objeto como cualquier cosa que tenga una frontera definida con nitidez. Considrese por un momento una planta de fabricacin que procesa materiales compuestos para fabricar elementos tan diversos como cuadros de bicicleta y alas de aeroplano. Las fbricas se dividen con frecuencia en talleres separados: mecnico, qumico, elctrico, etc. Los talleres se dividen adems en clulas, y en cada clula hay alguna coleccin de mquinas, como troqueladores, prensas y tornos. A lo largo de una lnea de fabricacin, se podra encontrar tanques con materias primas, que se utilizan en un proceso qumico para producir bloques de materiales compuestos, y a los que a su vez se da forma para producir elementos finales como cuadros para bicicletas y alas de aeroplano. Cada una de las cosas tangibles que se han mencionado hasta aqu es un objeto. Un torno tiene una frontera perfectamente ntida que lo separa del bloque de material compuesto sobre el que opera; un cuadro de bicicleta tiene una frontera perfectamente ntida que lo distingue de la clula o las mquinas que lo producen. Reconocimiento de objetos y clases en el mundo re Algunos objetos pueden tener lmites conceptuales precisos, pero an as pueden representar eventos o procesos intangibles. Por ejemplo, anlogamente, considrese un sistema CAD/CAM para modelar slidos. Donde se intersectan (intersecan) dos slidos como una esfera y un cubo, pueden formar una lnea irregular de interseccin. Aunque no existe fuera de la esfera o el cubo, esta lnea sigue siendo un objeto con fronteras conceptuales muy precisas. Algunos objetos pueden ser tangibles, y an as tener fronteras fsicas difusas. Objetos como los ros, la niebla o las multitudes humanas encajan en esta definicin3. Exactamente igual que la persona que sostiene un martillo tiende a verlo todo a su alrededor como un clavo, el desarrollador con una mentalidad orientada a objetos comienza a pensar que todo lo que hay en el mundo son objetos. Esta perspectiva es un poco ingenua, porque existen algunas cosas que claramente no son objetos. Por ejemplo, atributos como el tiempo, la belleza o el color no son objetos, ni las emociones como el amor o la ira. Por otro lado, todas estas cosas son potencialmente propiedades de otros objetos. Por ejemplo, se podra decir que un hombre (un objeto) ama a su mujer (otro objeto), o que cierto gato (un objeto ms) es gris. As, es til decir que un objeto es algo que tiene fronteras ntidamente definidas, pero esto no es suficiente para servir de gua al distinguir un objeto de otro, ni permite juzgar la calidad de las abstracciones. Por tanto, nuestra experiencia sugiere la siguiente definicin: Un objeto tiene estado, comportamiento e identidad; la estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables. Considrese una mquina expendedora de refrescos. El comportamiento usual de tales objetos es tal que cuando se introducen monedas en una ranura y se pulsa un botn para realizar una seleccin, surge una bebida de la mquina. Qu pasa si un usuario realiza primero la seleccin y a continuacin introduce dinero en la ranura? La mayora de las mquinas expendedoras se inhiben y no hacen nada, por que el usuario ha violado las suposiciones bsicas de su funcionamiento. Dicho de otro modo, la mquina expendedora estaba haciendo un papel (o esperando monedas) que el usuario ignor (haciendo primero la seleccin). Anlogamente, supngase que el usuario ignora la luz de advertencia que dice solo dinero exacto, e introduce dinero extra. La mayora de las mquinas son hostiles al usuario; se tragarn tan felices las monedas sobrantes. En todas esas circunstancias se ve cmo el comportamiento de un objeto est influenciado por su historia: el orden en el que se opera sobre el objeto es importante. La razn para este comportamiento dependiente del tiempo y los eventos es la existencia de un estado interior del objeto. Por ejemplo, un estado esencial asociado con la mquina

expendedora es la cantidad de dinero que acaba de introducir un usuario pero que an no se ha aplicado a una seleccin. Otras propiedades importantes incluyen la cantidad de cambio disponible y la cantidad de refrescos que tiene. 3 Esto es cierto solo a un nivel de abstraccin lo bastante alto. Para una persona que camina a travs de un banco de niebla, es generalmente intil distinguir mi niebla de tu niebla. Sin embargo, considrese un mapa meteorolgico: un banco de niebla sobre San Francisco es un objeto claramente distinto de un banco de niebla sobre Londres. Reconocimiento de objetos y clases en el mundo real De este ejemplo se puede extraer las siguientes definiciones de bajo nivel: El estado de un objeto abarca todas las propiedades (normalmente estticas) del mismo ms los valores actuales (normalmente dinmicos) de cada una de esas propiedades. El comportamiento es cmo acta y reacciona un objeto, en trminos de su cambio de estado y paso de mensajes. La identidad es aquella propiedad de un objeto que lo distingue de todos los dems objetos. Por tanto, a que nos referimos exactamente como un objeto? Ciertamente, las cosas fsicas son objetos. Un baln, un archivador, una agenda, un rbol y un computador son todos objetos. Qu pasa con objetos como un nmero, una palabra, una cuenta bancaria o una nota musical? No son objetos fsicos, pero son objetos porque tienen propiedades, o atributos, y podemos llevar a cabo acciones sobre ellos. Un nmero tiene un valor, y se pueden sumar dos nmeros. Una palabra tiene longitud y, si estamos hablando de un procesador de textos, se puede borrar o insertar una palabra en un documento. Una nota musical tiene tono, duracin y volumen. Casi siempre, algo es un objeto si tiene: Un nombre, Propiedades asociadas al mismo, Mensajes que puede entender. Tpicamente, cuando un objeto recibe un mensaje, se produce la ejecucin de una accin o cambia una propiedad del objeto como consecuencia de dicho mensaje. Clases Para comprender la naturaleza de una clase, se debern considerar dos niveles de definicin: el abstracto y el de instrumentacin. El nivel abstracto de una clase proporciona la esencia de la clase. En seguida se define una clase en el nivel abstracto. En el nivel abstracto, una clase se describe como una interfaz que define el comportamiento de sus objetos. Una clase se puede describir como una interfaz, porque su propsito principal es describir las operaciones, o funciones, que pueden realizar sus objetos. De esta manera, se define el comportamiento comn para todos sus objetos. Por comportamiento, se entiende cmo acta y reacciona un objeto de una clase dada cuando se acceda. La vista abstracta de una clase como una interfaz proporciona su vista de salida mientras oculta su estructura interna y detalles de comportamiento. De esta manera, un objeto de una clase dada se puede ver como una caja negra, como se muestra en la figura 1.1.

Figura 1.1 Al nivel abstracto, una clase es una interfaz que define el comportamiento de sus objetos. Es claro que la operacin o funcin interfaz proporciona un canal de comunicacin hacia el objeto clase y desde l. El programa de aplicacin genera una solicitud de operacin al objeto y ste responde con el resultado deseado. La interfaz dicta qu se debe suministrar al objeto y cmo responder ste. Como resultado, una clase, a travs de sus interfaces de operacin, define cmo se comportarn sus objetos. En el nivel de aplicacin cliente, se trata el objeto clase como una caja negra porque no interesa qu contiene el objeto, lo que interesa es cmo trabajar con l. Estos conceptos no debern ser nuevos para usted porque todo el tiempo ha estado usando las clases entero estndar, punto flotante y carcter. La instrumentacin de clase proporciona su vista interior, mostrando los secretos de la organizacin de sus datos e instrumentacin de funcin. Como resultado, la instrumentacin de clase revela los secretos de su comportamiento, porque se relaciona principalmente con las operaciones que definen el nivel abstracto o interfaz. En el nivel de instrumentacin, una clase es una unidad sintctica que describe una serie de datos y operaciones relacionadas que son comunes a sus objetos. La instrumentacin de una clase consiste en dos secciones principales: (1) una seccin pblica y (2) una privada. Cualquier elemento que se declare en una clase es un miembro de la clase. En consecuencia, para instrumentar una clase crearemos miembros pblicos y miembros privados. Clases

1.2 LA ABSTRACCION NATURAL

EL

ENCAPSULAMIENTO

COMO

UN

PROCESO

Las personas normalmente comprenden el mundo construyendo modelos mentales de parte de los mismos; tratan de comprender cosas con las que pueden interactuar: un modelo mental es una vista simplificada de cmo funciona de modo que se pueda interactuar contra ella. En esencia, este proceso de construccin de modelos es lo mismo que el diseo de software, aunque el desarrollo de software es nico. El diseo de software produce el modelo que puede se manipulado por una computadora. La abstraccin es esencial para el funcionamiento de una mente humana normal y es una herramienta muy potente para tratar la complejidad. Considerar, por ejemplo, el ejercicio mental de memorizar nmeros. Un total de siete dgitos se puede memorizar con ms o menos facilidad. Sin embargo, si se agrupan y se denominan nmeros de telfono, los dgitos individuales se relegan en sus detalles de ms bajo nivel, crendose un nivel abstracto y ms alto, en el que los siete nmeros se organizan en una nica entidad. Utilizando este mecanismo se puede memorizar algunos nmeros de telfonos, de modo que la agrupacin de diferentes entidades conceptuales es un mecanismo potente al servicio de la abstraccin. La abstraccin es una de las vas fundamentales por la que los humanos combatimos la complejidad. Hoare sugiere que la abstraccin surge de un reconocimiento de las similitudes entre ciertos objetos, situaciones o procesos del mundo real, la decisin de concentrarse en esas similitudes e ignorar por el momento las diferencias. Shaw define una abstraccin como una descripcin simplificada o especificacin de un sistema que enfatiza algunos de los detalles o propiedades del mismo mientras suprime otros. Una buena abstraccin es aquella que enfatiza detalles significativos al lector o usuario y suprime detalles que son, al menos por el momento, irrelevantes o causa de distraccin. Berzins, Gray y Naumann recomiendan que un concepto merece el calificativo de abstraccin solo si se puede describir, comprender y analizar independientemente del mecanismo que vaya a utilizarse eventualmente para realizarlo. Combinando estos diferentes puntos de vista se define una abstraccin del modo siguiente: Una abstraccin denota las caractersticas esenciales de un objeto que lo distinguen de todos los dems tipos de objeto y proporciona as fronteras conceptuales ntidamente definidas respecto a la perspectiva del observador. Una abstraccin se centra en la visin externa de un objeto y, por tanto, sirve para separar el comportamiento esencial de un objeto de su implantacin. Seidewitz y Stara sugieren que existe una gama de abstraccin, desde los objetos que modelan muy de cerca entidades del dominio del problema a objetos que no tienen una verdadera razn para existir. De mayor a menor utilidad, estos tipos de abstraccin incluyen: Abstraccin de entidades. Un objeto que representa un modelo til de una entidad del dominio del problema o del dominio de la solucin. Abstraccin de acciones. Un objeto que proporciona un conjunto generalizado de operaciones, y todas ellas desempean funciones del mismo tipo. Abstraccin de mquinas. Un objeto que agrupa operaciones, todas ellas virtualesutilizadas por algn nivel superior de control, u operaciones que utilizan todas algn conjunto de operaciones de nivel inferior.bstraccin y Abstraccin de coincidencia. Un objeto que almacena un conjunto de operaciones que no tiene relacin entre s. Se persigue construir abstracciones de entidades, porque imitan directamente el vocabulario de un determinado dominio de problema.

Encapsulamiento Dicho sencillamente, la abstraccin de un objeto debera preceder a las decisiones sobre su implementacin. Una vez que se ha seleccionado una implantacin, debe tratarse como un secreto de la abstraccin, oculto para la mayora de los clientes. Como sugiere sabiamente Ingalls, ninguna parte de un sistema complejo debe depender de los detalles internos de otras partes. Mientras que la abstraccin ayuda a las personas a pensar lo que estn haciendo, el encapsulamiento permite que los cambios hechos en los programas sean fiables con el menor esfuerzo. La abstraccin y el encapsulamiento son conceptos complementarios: la abstraccin se centra en el comportamiento observable de un objeto, mientras el encapsulamiento se centra en la implementacin que da lugar a este comportamiento. El encapsulamiento se consigue a menudo mediante la ocultacin de informacin, que es el proceso de ocultar todos los secretos de un objeto que no contribuye a sus caractersticas esenciales; tpicamente, la estructura de un objeto esta oculta, as como la implantacin de sus mtodos. El encapsulamiento proporciona barreras explcitas entre abstracciones diferentes y por tanto conduce a una clara separacin de intereses. Por ejemplo considrese la estructura de una planta. Para comprender como funciona la fotosntesis a un nivel alto de abstraccin, se pueden ignorar detalles como los cometidos de las races de la planta o la qumica de las paredes de las clulas. Anlogamente, al disear una aplicacin de bases de datos, es prctica comn el escribir programa de forma que no se preocupen de la representacin fsica de los datos, sin que dependan solo de un esquema que denota la vista lgica de los mismos. Los objetos a un nivel de abstraccin estn protegidos de los detalles de implementacin a niveles ms bajos de abstraccin. Liskow llega a sugerir que para que la abstraccin funcione, la implementacin debe estar encapsulada. En la prctica esto significa que cada clase debe tener dos partes: un interfaz y una implementacin. El interfaz2 de una clase captura slo su vista externa, abarcando la abstraccin que se ha hecho del comportamiento comn de todas las instancias de la clase. La implementacin (implantacin) de una clase comprende la representacin de la abstraccin as como de los mecanismos que consiguen el comportamiento deseado. El interfaz de una clase es el nico lugar en el que se declaran todas las suposiciones que un cliente puede hacer acerca de todas las instancias de la clase: la implantacin encapsula detalles acerca de los cuales ningn cliente puede realizar suposiciones. 2 Se suele utilizar tambin el trmino con gnero femenino: la interfaz. (N del T). La abstraccin y el encapsulamiento como un proceso natural Para resumir, se define el encapsulamiento como sigue: El encapsulamiento es el proceso de almacenar en un mismo compartimento de los elementos de una de una abstraccin que constituye su estructura y su comportamiento; sirve para separar el interfaz contractual de una abstraccin y su implantacin. Britton y Parnas llaman a esos elementos encapsulados los secretos de una abstraccin.

1.3 LA POO Y LA COMPLEJIDAD DEL SOFTWARE La abstraccin es la clave para disear buen software. En los primeros das de la informtica, los programadores enviaban instrucciones binaras a una computadora, manipulando directamente interrupciones en sus partes frontales. Los nemotcnicos del lenguaje ensamblador eran abstracciones diseadas para evitar que los programadores tuvieran que recordar las secuencias de bits que componen las instrucciones de un programa. El siguiente nivel de abstraccin se consigue agrupando instrucciones primitivas para formar macroinstrucciones. Por ejemplo, un conjunto se puede definir por abstraccin como una coleccin no ordenada de elementos en el que no existen duplicados. Utilizando esta definicin, se puede especificar si sus elementos se almacenan en un array, una lista enlazada o cualquier otra estructura de datos. Un conjunto de instrucciones realizadas por un usuario se pueden invocar por una macroinstruccin; una macroinstruccin instruye a la mquina para que realice muchas cosas. Tras los lenguajes de programacin ensambladores aparecieron los lenguajes de programacin de alto nivel, que supusieron un nuevo nivel de abstraccin. Los lenguajes de programacin de alto nivel permitieron a los programadores distanciarse de las interioridades arquitectnicas especficas de una mquina dada. Cada instruccin en un lenguaje de alto nivel puede invocar varias instrucciones mquina, dependiendo de la mquina especfica donde se compila el programa. Esta abstraccin permita a los programadores escribir software para propsito genrico, sin preocuparse sobre que mquina corre el programa. El proceso de abstraccin fue evolucionando desde la aparicin de los primeros lenguajes de programacin. El mtodo ms idneo para controlar la complejidad fue aumentar los niveles de abstraccin. En esencia la abstraccin supone la capacidad de encapsular y aislar la informacindel diseo y ejecucin. En un determinado sentido, las tcnicas orientadas a objetos pueden verse como un producto natural de una larga progresin histrica que va desde las estructuras de control, pasando por los procedimientos, los mdulos, los tipos abstractos de datos y los objetos Una estrella moribunda al borde el colapso, un nio aprendiendo a leer, glbulos blancos que apresuran a atacar a un virus: no son ms que unos pocos de los objetos del mundo fsico que conllevan una complejidad verdaderamente aterradora. El software puede tambin involucrar elementos de gran complejidad; sin embargo, la complejidad que se encuentra aqu es de un tipo fundamentalmente diferente. Como apunta Einstein arguy que debe haber explicaciones simplificadas de la naturaleza, porque Dios no es caprichoso ni arbitrario. No hay fe semejante que conforte al ingeniero del software. Mucha de la complejidad que debe dominar es complejidad arbitraria.La Ya se sabe que algunos sistemas de software no son complejos. Son las aplicaciones altamente intranscendentes que son especificadas, construidas, mantenidas y utilizadas por la misma persona, habitualmente el programador aficionado o el desarrollador profesional que trabaja en solitario. Esto no significa que todos estos sistemas sean toscos o poco elegantes, ni se pretende quitar mrito a sus creadores. Tales sistemas tienden a tener un propsito muy limitado y un ciclo de vida muy corto. Uno puede permitirse tirarlos a la basura y reemplazarlos con software completamente nuevo en lugar de intentar reutilizarlos, repararlos o extender su funcionalidad. El desarrollo de estas aplicaciones es generalmente ms tedioso que difcil; por consiguiente, el aprender a disearlas es algo que no nos interesa. En lugar de eso, interesan mucho ms los desafos que plantea el desarrollo de lo que llamaremos software de dimensin industrial. La caracterstica distintiva del software de dimensin industrial es que resulta sumamente difcil, si no imposible, para el desarrollador individual comprender todas las sutilidades de su diseo. Para hablar claro,

la complejidad de tales sistemas excede la capacidad intelectual humana. Lamentablemente, la complejidad de la que se habla parece ser una propiedad esencial de todos los sistemas de software de gran tamao. Con esencial quiere decirse que puede dominarse esa complejidad, pero nunca eliminarla . Por qu el software es complejo de forma innata. Como sugiere Brooks, la complejidad del software es una propiedad esencial, no accidental. Se observa que esta complejidad del dominio del problema, la dificultad de gestionar el proceso de desarrollo, la flexibilidad que se puede alcanzar a travs del software y los problemas que plantea la caracterizacin del comportamiento de sistemas discretos. La complejidad del dominio del problema. Los problemas que se intentan resolver con el software conllevan a menudo elementos de complejidad ineludibles, en los que se encuentra una mirada3 de requisitos que compiten entre s, que quizs incluso se contradicen. Considrense los requisitos para el sistema electrnico de un avin multimotor, un sistema de conmutacin para telfonos celulares o un robot autnomo. La funcionalidad pura de tales sistemas es difcil incluso de comprender, pero adanse adems todos los requerimientos no funcionales, tales como facilidad de uso, rendimiento, coste, capacidad de supervivencia y fiabilidad, que a menudo estn implcitos. Esta ilimitada complejidad externa es lo que causa la complejidad arbitraria a la que Brooks se refiere. Esta complejidad externa surge habitualmente de desacoplamiento de impedancia que existe entre los usuario de un sistema y sus desarrolladores; los usuarios suelen encontrar grandes dificultades al intenta expresa con precisin sus necesidades en una forma que los desarrolladores puedan comprender. En casos extremos, los usuarios pueden no tener ms que ideas vagas de lo que desean de un sistema de software. Esto no es en realidad achacable a los usuarios ni a los desarrolladores del sistema; ms bien ocurre porque cada uno de los grupos no suele conocer suficientemente el dominio del otro. Los usuarios y los desarrolladores tienen perspectivas diferentes sobre la naturaleza del problema y realizan diferentes suposiciones sobre la naturaleza de la solucin. En la actualidad, an cuando los usuarios tuviesen un conocimiento perfecto de sus necesidades, se dispone de pocos instrumentos para plasmar estos requisitos con exactitud. La forma habitual de expresar requisitos hoy en da es mediante grandes cantidades de texto, ocasionalmente acompaadas de unos pocos dibujos. Estos documentos son difciles de comprender, estn abiertos a diversas interpretaciones, y demasiado frecuentemente contienen elementos que invaden el diseo en lugar de limitarse a ser requisitos esenciales. Ya que un sistema grande de software es una inversin considerable, no es admisible el desechar un sistema existente cada vez que los requerimientos cambian. Est o no previsto, los sistemas grandes tienden a evolucionar en el tiempo, situacin que con frecuencia se etiqueta de forma incorrecta con el trmino mantenimiento del software. Siendo precisos, es mantenimiento cuando se corrigen errores; es evolucin cuando de responde a requerimientos que cambian; es conservacin cuando se sigue empleando medios extraordinarios para mantener en operacin un elemento de software anticuado y decadente. Desafortunadamente, la realidad sugiere que un porcentaje exagerado de los recursos de desarrollo del software se emplean en conservacin del mismo.

1.4 CONCEPTOS DEL CICLO DE VIDA DEL SOFTWARE El desarrollo de software va unido a un ciclo de vida compuesto por una serie de etapas que comprenden todas las actividades, desde el momento en que surge la idea de crear un nuevo producto software, hasta aquel en que el producto deja definitivamente de ser utilizado por el ltimo de sus usuarios. La definicin de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al software, a continuacin dos conceptos: Una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin y el mantenimiento del software IEEE 10744 Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotacin y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definicin de los requisitos hasta la finalizacin de su uso ISO 12207-15 4 Standard for Developing Software Life Cycle Processes, Institute of Electrical and Electronics Engineers. 5 International Standard Software Life Cycle Processes, International Organization for Standardization. Conceptos del ciclo de vida del software 1.4.1 Especificaciones De Requerimientos. En el desarrollo de un proyecto intervienen diferentes etapas que se interrelacionan y complementan para y con la finalidad de alcanzar los objetivos iniciales, veamos las etapas con que podemos contar a lo largo del ciclo de vida del software:

Figura 1.2 Elementos del Ciclo de vida del Software.

Expresin de necesidades. Esta etapa tiene como objetivo la consecucin de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecer al usuario del sistema a desarrollar (qu, y no cmo, se va a desarrollar). Dado que normalmente se trata de necesidades del cliente para el que se crear la aplicacin, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relacin comercial, siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial). Especificaciones. Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomar como punto de partida para esta fase. Su contenido es an insuficiente y lleno de imprecisiones que ser necesario completar y depurar. Por medio de esta etapa se obtendr un nuevo documento que definir con ms precisin el sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy buena eleccin para llevar a cabo la especificacin del sistema). Lo ms normal ser que no resulte posible obtener una buena especificacin del sistema a la primera; sern necesarias sucesivas versiones del documento en que irn quedando reflejada la evolucin de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones de los ya contemplados). Anlisis. Es necesario determinar que elementos intervienen en el sistema a desarrollar, as como su estructura, relaciones, evolucin en el tiempo, detalle de sus funcionalidades, ... que van a dar una descripcin clara de qu sistema vamos a construir, qu funcionalidades va a aportar y qu comportamiento va a tener. Para ello se enfocar el sistema desde tres puntos de vista relacionados pero diferentes: Funcional. Esttico. Dinmico. Diseo Diseo Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo (cmo debe ser construido el sistema?; aqu se definirn en detalle entidades y relaciones de las bases de datos, se pasar de casos de uso esenciales a su definicin como casos expandidos reales, se seleccionar el lenguaje ms adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, libreras, configuraciones hardware, redes, etc.). Aunque todo debe ser tratado a su tiempo, y sera muy deseable que las decisiones correspondientes en esta etapa fueran tomadas precisamente en esta etapa, muchas veces nos vamos a encontrar con unas decisiones previamente impuestas sobre lenguaje, plataforma, etc. Unas veces se dirn justificadas en simple poltica de empresa y por mantener "compatibilidad" en lo que respecta a los dems proyectos de la propia empresa, y en otras ocasiones por rumores de que tal o cual herramienta mejorara la velocidad de desarrollo u otro aspecto de inters (en parte de los casos no sern rumores con fundamento o estudios previos realizados al efecto, sino ms bien debidos a la propia publicidad como consejera).

Implementacin. Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programacin y/o para un determinado sistema gestor de bases de datos. Lamentablemente en la actualidad, quedan bastantes empresas en las que, tras una reunin comercial en que tan solo se ha conseguido recabar una breve lista de requerimientos, a pesar de tener que enfrentarse a proyectos grandes-medios, se pasa directamente a la etapa de implementacin; son proyectos guiados por el riesgo que supone adoptar un modelo de ciclo de vida de codificar-corregir (code and fix) donde se eliminan las fases de especificaciones, anlisis y diseo con la consiguiente prdida de control sobre la gestin del proyecto. Especificaciones de requerimientos Pruebas. El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseo y/o programacin. Es conveniente que sean planteadas al menos tanto a nivel de cada mdulo (aislado del resto), como de integracin del sistema (segn sea la naturaleza del proyecto en cuestin se podrn tener en cuenta pruebas adicionales, p.e. de rendimiento). Validacin. Esta etapa tiene como objetivo la verificacin de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase tambin es interesante contar con los use cases, generados a travs de las correspondientes fases previas, que servirn de gua para la verificacin de que el sistema cumple con lo descrito por estos). Mantenimiento y Evolucin. Finalmente la aplicacin resultante se encuentra ya en fase de produccin (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondr ya pequeas operaciones tanto de correccin como de mejora de la aplicacin (p.e. mejora del rendimiento), as como otras de mayor importancia, fruto de la propia evolucin (p.e. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto). La mayora de las veces en que se desarrolla una nueva aplicacin, se piensa solamente en un ciclo de vida para su creacin, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrn que producirse con casi completa seguridad para la mayor parte de los casos). 1.4.2 Anlisis Orientado A Objetos. El modelo de objetos ha influido incluso en las fases iniciales del ciclo de vida del desarrollo del software. Las tcnicas de anlisis estructurado tradicionales, cuyo mejor ejemplo son los trabajos de DeMarco, Yourdon y Gane y Sarson, con extensiones para tiempo real Ward y Mellor y de Hattley y Pirbhai, se centran en el flujo de datos dentro de un sistema. El anlisis orientado a objetos (AOO, como se le llama en ocasiones) enfatiza la construccin de modelos del mundo real, utilizando una visin del mundo orientada a objetos: El anlisis orientado a objetos es un mtodo de anlisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema. Anlisis Orientado a Objetos

1.4.3 Diseo Orientado A Objetos. Para sustentar los principios descritos anteriormente, se han desarrollado distintas metodologas de diseo y programacin. Recientemente, un enfoque, el diseo y la programacin orientada a objetos, se ha mostrado particularmente prometedor para ayudar a los fabricantes de software a lograr los objetivos de fiabilidad, rendimiento, adaptabilidad, comprensibilidad y reutilidad. El diseo de software orientado a objeto anima a pensar en el software como un modelo muy prximo a la forma en que pensamos, e interaccionamos con l, en el mundo real. En edad temprana, aprendemos acerca de los objetos y de cmo se manipulan. Los bebs, aprende que si mueven un sonajero har ruido. Ms tarde, a medida que se desarrollan las capacidades cognitivas, somos concientes de que los objetos tienen propiedades y empezamos a pensar en ellos de forma abstracta. Por ejemplo, un beb crecido pronto se da cuenta de que hacer ruido es una capacidad de todos los sonajeros. El nfasis en los mtodos de programacin esta puesto principalmente en el uso correcto y efectivo de mecanismos particulares del lenguaje que utiliza. Por contraste, los mtodos de diseo enfatizan la estructuracin correcta y efectiva de un sistema complejo. Qu es entonces el diseo orientado a objetos? Sugerimos que. El diseo orientado a objetos es un mtodo de diseo que abarca el proceso de descomposicin orientada a objetos y una notacin para describir los modelos lgico y fsico, as como los modelos esttico y dinmico del sistema que disea. . 1.4.4. Programacin Orientada A Objetos, Conceptos Y Caractersticas. La orientacin a objetos puede describirse como el conjunto de disciplinas (ingeniera) que desarrollan y modelizan software que facilitan la construccin de sistemas complejos a partir de componentes. El atractivo intuitivo de la orientacin a objetos es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible. Las ventajas de la orientacin a objetos son muchas en programacin y modelacin de datos. Como apuntaban Ledbetter y Cox (1985): La programacin orientada a objetos permite una representacin ms directa del modelo de mundo real en el cdigo. El resultado es que la transformacin radical normal de los requisitos de sistema (definido en trminos de usuario) se reduce considerablemente. Qu es entonces la programacin orientada a objetos (o POO, como se escribe a veces)? Aqu va a definirse como sigue: La programacin orientada a objetos es un mtodo de implementacin en que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son, todas ellas, miembros de una jerarqua de clases unidas mediante relaciones de herencia. Hay tres caractersticas importantes: 1. Utiliza objetos, no algoritmos, como sus bloques lgicos de construccin fundamentales. 2. Cada objeto es una instancia de alguna clase 3. Las clases estn relacionadas con otras clases por medio de relaciones de herencia.

1.5 ELEMENTOS PRIMORDIALES EN EL MODELO DE OBJETOS Los elementos ms importantes que deben tener los objetos de software que sirven como base sobre las cuales se fundamenta la programacin orientada a objetos, para cumplir con el paradigma de orientacin a objetos son: Abstraccin Encapsulamiento Modularidad. Herencia y Jerarqua. Polimorfismo. Cada uno de estos puntos requiere de una actitud mental diferente, una forma distinta de pensar en el problema. Para todas las cosas orientadas a objetos, el marco de referencia conceptual es el modelo de objetos. 1.5.1 Abstraccin La abstraccin es uno de los medios ms importantes, mediante el cual nos enfrentamos con la complejidad inherente al software. La abstraccin es el proceso de simplificar un problema complejo. Al abordar la solucin de un problema, uno no se abruma con cada uno de los detalles, mas bien, lo simplifica enfocndose tan slo en los aspectos relevantes para la solucin. Una abstraccin se centra en la vista externa de un objeto, de un modo que sirva para separar el comportamiento esencial de un objeto de su implementacin. Definir una abstraccin significa describir una entidad del mundo real, no importa lo compleja que pueda ser, y a continuacin utilizar esta descripcin en un programa. El elemento clave de la programacin orientada a objetos es la clase. Una clase se puede definir como una descripcin abstracta de un grupo de objetos, cada uno de los cuales se diferencia por su estado especfico y por la posibilidad de realizar una serie de operaciones. Por ejemplo, un pluma estilogrfica es un objeto que tienen un estado (llena de tinta o vaca) y sobre la cual se pueden realizar algunas operaciones (por ejemplo escribir, poner o quitar el capuchn, llenar de tinta si est vaca). La idea de escribir programas definiendo una serie de abstracciones no es nueva, pero el uso de clases para gestionar dichas abstracciones en lenguajes de programacin ha facilitado considerablemente su aplicacin. n Encapsulacin 1.5.2 Encapsulacin La encapsulacin o encapsulamiento es la propiedad que permite asegurar que el contenido de la informacin de un objeto est oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B, y viceversa. La encapsulacin (tambin se conoce como ocultacin de la informacin), en esencia, es el proceso de ocultar todos los objetos de un objeto que no contribuyen a sus caractersticas esenciales. La encapsulacin permite la divisin de un programa en mdulos. Estos mdulos se implementan mediante clases, de forma que una clase representa la encapsulacin de una abstraccin. En la prctica, esto significa que cada clase debe tener dos partes una interfaz y una implementacin. El interfaz de una clase captura solo su vista externa y la implementacin contiene la representacin de la abstraccin, as como los mecanismos que realizan el comportamiento deseado.

1.5.3 Modularidad La modularidad es la propiedad que permite subdividir una aplicacin en partes ms pequeas (llamadas mdulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicacin en si y de las restantes partes. La modularizacin, consiste en dividir un programa en mdulos que se puedan compilar por separado, pero que tienen conexiones con otros mdulos. Al igual que la encapsulacin, los lenguajes soportan la modularidad de diversas formas. Por ejemplo, en C++ los mdulos son archivos compilados por separado. La prctica usual es situar los interfaces de los mdulos en archivos con nombres con extensin .h (archivos de cabecera) y las implementaciones de los mdulos se sita en archivos con nombre con extensin .cpp. La modularidad es la propiedad de un sistema que permite su descomposicin en un conjunto de mdulos cohesivos y dbilmente acoplados. 1.5.4 Herencia Y Jerarqua Una de las propiedades ms importantes de la programacin orientada a objetos es la herencia. De hecho, algunos piensan que un programa que no emplea herencia no es un programa orientado a objetos. La herencia es aquella propiedad de la programacin orientada a objetos que le permite a una clase, llamada clase derivada, compartir la estructura y el comportamiento de otra clase, llamada clase base. La naturaleza est llena de herencia. Todas las cosas vivas heredan las caractersticas o rasgos de sus antepasados. Aunque usted es diferente de sus padres en muchos sentidos, tambin es igual en muchas formas debido a los rasgos genticos que ha heredado de ellos. En la programacin orientada a objetos, la herencia permite que las clases recin creadas hereden miembros de clases existentes. Estas nuevas clases derivadas o hijos, incluirn sus propios miembros y miembros heredados de las clases base o padres. De esta manera, es posible ver una coleccin de clases con miembros heredados comunes como una familia de clases, como aqulla a la que usted pertenece. Las clases se relacionan una con otra a travs de la herencia. Tal herencia crea una jerarqua de clase. Una razn para usar herencia es que le permite reutilizar el cdigo de un proyecto de programacin anterior sin empezar de cero para reinventar el cdigo. Muchas veces es posible reutilizar el cdigo desarrollado para un programa en otro programa. Aunque el nuevo programa sea ligeramente diferente del anterior, la herencia permite construir uno que fue hecho con anterioridad. Por qu reinventar la rueda? Otra razn para usar herencia es que permite construir una jerarqua entre clases. Las clases que incluyen aquellas cosas que se heredan ms comnmente se encuentran en la parte superior de la jerarqua, justo como sus antepasados estn en la parte superior de la jerarqua de su familia gentica. La jerarqua es una propiedad que permite una ordenacin de las abstracciones. Las dos jerarquas mas importantes de un sistema complejo son: estructura de clases (jerarqua esun (isa): generalizacin/especializacin) y una estructura de objetos (jerarqua partede (part of): agregacin). Las jerarquas de generalizacin/especializacin se conocen como herencia. Bsicamente, la herencia define una relacin entre clases, en donde una clase comparte la estructura o comportamiento definido en una o mas clases (herencia simple y herencia mltiple, respectivamente). La agregacin es el concepto que permite el agrupamiento fsico de estructuras relacionadas lgicamente. As, un camin se compone de ruedas, motor, sistema de transmisin y chasis; en consecuencia, camin es una agregacin y ruedas, motor, transmisin y chasis son agregados de camin.

1.5.5 Polimorfismo La quinta propiedad significativa de los lenguajes de programacin orientados a objetos es el polimorfismo. Caracterstica fundamental de la POO, que no es otra cosa que la posibilidad de construir varios mtodos con el mismo nombre, pero con relacin a la clase a la que pertenece cada uno, con comportamientos diferentes. Esta propiedad no suele ser considerada como fundamental en los diferentes modelos de los objetos propuestos, pero, dada su importancia, no tiene sentido considerar un objeto modelo que no soporte esta propiedad. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibiran el mismo mensaje global pero responderan a l de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significara suma, mientras que para un objeto STRING significara concatenacin ("pegar" strings uno seguido al otro). o Historia de los paradigmas en el desarrollo del software Polimorfismo es la propiedad que indica, literalmente, la posibilidad de que una entidad tome muchas formas. En trminos prcticos, el polimorfismo permite a objetos de clases diferentes mediante el mismo elemento de programa y realizar la misma operacin de diferentes formas, segn sea el objeto que se referencia en ese momento.

1.6 HISTORIA DE LOS PARADIGMAS EN EL DESARROLLO DEL SOFTWARE La programacin orientada a objetos (POO) se suele conocer como un nuevo paradigma de programacin. Otros paradigmas conocidos son: el paradigma de la programacin imperativa (con lenguajes tales como Pascal o C), el paradigma de la programacin lgica (PROLOG) y el paradigma de la programacin funcional (Lisp). El significado de paradigma (paradigma en latn; paradeigma en griego) en su origen significaba un ejemplo ilustrativo, en particular enunciado modelo que mostraba todas las inflexiones de una palabra. En el libro The Structure of Scientific Revolutions, el historiador Thomas Kuhn describa un paradigma como un conjunto de teoras, estndar y mtodos que juntos representan un medio de organizacin del conocimiento: es decir, un medio de visualizar el mundo. En este sentido, la programacin orientada a objetos es un nuevo paradigma. La orientacin a objetos fuerza a reconsiderar nuestro pensamiento sobre la computacin, sobre lo que significa realizar computacin y sobre como se estructura la informacin dentro del computador. Jenkis y Glasgow observan que la mayora de los programadores trabajan en un lenguaje y utilizan solo un estilo de programacin, ellos programan en un paradigma forzado por el lenguaje que utilizan. Con frecuencia, no se enfrentan a mtodos alternativos de resolucin de un problema, y por consiguiente tienen dificultad en ver una ventaja de elegir un estilo ms apropiado al problema a manejar. Bobrow y Stefik definen un estilo de programacin como un medio de organizacin de programas sobre la base de algn modelo conceptual de programacin y un lenguaje apropiado para hacer programas en un estilo claro.Sugieren que existen cuatro clases de estilos de programacin: Orientacin a procedimientos Algoritmos Orientacin a objetos Clases y objetos Orientacin a lgica Expresado en calculo de predicados Orientacin a reglas Reglas if then

No existe ningn estilo de programacin idneo para todas las clases de programacin. La orientacin a objetos se acopla a la simulacin de situaciones del mundo real. En POO, las entidades centrales son los objetos, que son tipos de datos que encapsulan con el mismo nombre estructuras de datos y las operaciones o algoritmos que manipulan esos datos. El primer lenguaje de programacin que introdujo el concepto de clase fue Simula 6-7, como entidad que contena datos y las operaciones que manipulaban los datos. Asimismo, introdujo tambin el concepto de herencia. El siguiente lenguaje orientado a objetos, y seguramente el ms popular desde un enfoque conceptual exclusivamente de objetos, es Smalltalk, cuya primera versin comercial se desarroll en 1976, y en 1980 se populariz con la aparicin de Smalltalk-80. Posteriormente se ha popularizado gracias al desarrollo de Smalltalk/V de la casa Digital Y, que recientemente se ha implementado bajo entorno Windows. El lenguaje se caracteriza por soportar todas las propiedades fundamentales de la orientacin a objetos, dentro de un entorno integrado de desarrollo, con interfaz interactivo de usuario basado en mens. Entre los lenguajes orientados a objetos que se han desarrollado a partir de los ochenta destacan extensiones de lenguajes tradicionales tales como C++ y Objective-C (extensiones de C), Modula-2 y Object Pascal (extensin de Pascal) y recientemente Object Cobol, que a lo largo de 1994 han aparecido sus primeras versiones comerciales, y java, el nuevo lenguaje para programacin en Internet. Otro lenguaje orientado a objetos puros es Eiffel, creado por Bertrand Meyer y que soporta todas las propiedades fundamentales de los objetos. Ada ha sido tambin un lenguajeen este caso basado en objetos que soporta la mayora de las propiedades orientadas a objetos. Sin embargo, la versin Ada-95 ya soporta herencia y polimorfismo.

Figura 1.3 Evolucin de los lenguajes orientados a objetos La normalizacin de ANSI y AT&T de la versin 3.0 y las numerosas versiones de diferentes fabricantes, tales como Borland C++ 4.0/4.5 Turbo C++ 3.0/3.1 y 4.5, Microsoft C/C++ 7.0, Visual C++ 1.5/2, Symantec 6.0/7.0, etctera, hicieron que en los noventa fueran los lenguajes orientados a objetos mas populares y utilizados en el mundo de la programacin. La evolucin de los lenguajes orientados a objetos se han mostrado en la figura 1.2, en la que se aprciale tronco comn a todos los lenguajes modernos de algol y

las tres lneas fundamentales: enfoque en Pascal (Ada, Object Pascal), enfoque puro de orientacin a objetos (Simula/Smalltalk/Eiffel) y enfoque en C (Objective-C, C++, Java). de los paradigmas en el desarrollo del software Clasificacin de los lenguajes orientados a objetos. Existen varias clasificaciones de lenguajes de programacin orientados a objetos, atendiendo a criterios de construccin o caractersticas especificas de los mismos. Una clasificacin ampliamente aceptada y difundida es la dada por Wegner y que ilustra en la figura.

Figura 1.4 Clasificacin de Wegner La clasificacin de Wegner divide los lenguajes en tres categoras: 1. Lenguajes basados en objetos que soportan objetos. Es decir, disponen de componentes caracterizados por un conjunto de operaciones (comportamiento) y un estado 2. Lenguajes basados en clases que implica objetos y clases. Es decir, disponen de componentes tipo clase con operaciones y estado comn. Una clase de un objeto se construye con un interfaz que especifica las operaciones posibles y un cuerpo que implementa dichas operaciones. 3. Lenguajes orientados a objetos que adems de objetos y clases ofrecen mecanismos de herencia entre clases. Esto es la posibilidad de derivar operaciones y atributos de una clase (superclase) a sus subclase.

1.7 BENEFICIOS DEL MODELO DE OBJETOS Y DE LA POO SOBRE OTROS PARADIGMAS La programacin orientada a objetos es una tcnica para programar: un paradigma para escribir buenos programas para un conjunto de problemas. El apoyo para un paradigma no viene solo en la forma obvia de los recursos del lenguaje que permiten emplear directamente el paradigma, sino tambin en la forma ms sutil de verificaciones en los tiempos de compilacin o ejecucin, o ambos, contra desviaciones no intencionales respecto al paradigma. La verificacin de tipos es el ejemplo mas obvio de esto; la deteccin de ambigedades y las verificaciones durante la ejecucin pude servir para ampliar el apoyo lingstico de los paradigmas. Los recursos extra lingsticos, como las bibliotecas estndar y los ambientes de programacin, pueden proporcionar tambin un apoyo importante para los paradigmas. Un lenguaje no es por fuerza mejor que otro por poseer una caracterstica de la que carece el otro. Existen muchos ejemplos de lo contrario. Lo importante no es tanto que caractersticas posee un lenguaje, sino que estas sean suficientes para apoyar los estilos de programacin deseados en las reas de aplicaciones deseadas: Todas las caractersticas deben estar integradas al lenguaje en forma muy limpia y elegante. Debe ser posible utilizar una combinacin de caractersticas distintivas para lograr soluciones que de otra manera habran requerido caractersticas independientes adicionales. El numero de caractersticas espurias y de aplicacin especial debe ser lo mas bajo posible. La realizacin de un rasgo distintivo no debe implicar un gasto extra significativo para los programas que no lo requieran. Un usuario solo necesita saber acerca del subconjunto del lenguaje empleado explcitamente para escribir un programa. Cuando se construye un automvil, un edificio o un dispositivo electrnico, se ensamblan una serie de piezas independientes, de modo que estos componentes se reutilicen, en vez de fabricarlos cada vez que se necesita construir un automvil o un edificio. En la construccin de software, esta pregunta es continua. Por qu no se utilizan programas ya construidos para formar programas ms grandes? Es decir, si en electrnica los computadores y sus perifricos se forman esencialmente con el ensamblado de circuitos integrados, existe algn mtodo que permita realizar grandes programas a partir de la utilizacin de otros programas ya realizados? Es posible reutilizar estos componentes de software? El Dr. Ian Graham, en su libro Mtodos Orientados a Objetos nos habla acerca de que los mtodos orientados a objetos, en general, y la programacin orientada a objetos, en particular, ofrecen diversas ventajas tanto a los diseadores como a los usuarios del software. Estas ventajas tienen, en buena parte, el mismo carcter general que las que ofrecen la programacin y el diseo estructurado, pero van ms all en algunas direcciones y, al hacerlo, nos llevan a dudar de la validez de muchos de los supuestos bsicos de la escuela de pensamiento de los mtodos estructurados. Adelantando nuestro anlisis, tenemos que las principales ventajas son las siguientes: Los objetos bien diseados en los sistemas orientados a objetos constituyen la base para otros sistemas que se ensamblan, en gran parte, a partir de mdulos reutilizables, lo que redunda en una mayor productividad. Esta es, quizs, la ventaja ms conocida de la tecnologa de objetos. La reutilizacin de clases existentes, que han sido probadas en proyectos anteriores, conduce a la elaboracin de sistemas de mayor calidad, que satisfacen mejor los requisitos de negocios y contienen menos errores.

 La programacin orientada a objetos, y la herencia en particular, hacen que sea posible utilizar y definir de forma clara mdulos funcionalmente incompletos y, luego, permiten su extensin sin trastornar la operacin de otros mdulos o de sus clientes. Esto hace que los sistemas sean ms flexibles, ms fcilmente extensibles y de mantenimiento menos costoso. La convencin de paso de mensajes para la comunicacin entre objetos lleva a que las descripciones de la interfaz entre mdulos y sistemas externos se haga mucho ms fcil. Tambin facilita la descripcin y la construccin de interfaces grficas de usuario y sistemas distribuidos. Dividir los sistemas tomando como base tipos de objetos encapsulados ayuda a resolver el problema de la escalabilidad. No hay razn para que el esfuerzo tenga que aumentar exponencialmente con el tamao y la complejidad del proyecto, tal como sucede con los sistemas convencionales. El ocultamiento de informacin contribuye a construir sistemas seguros. La aproximacin de diseo centrado en datos, propia del anlisis orientado a objetos, al incluir tambin los procesos, es capaz de capturar una mayor parte de la semntica del modelo de forma realizable. Esto es muy importante en los sistemas comerciales y, en especial, en los sistemas de bases de datos. La evolucin de un sistema y los problemas de mantenimiento quedan mitigados por la slida particin que resulta del encapsulamiento y de las interfaces uniformes entre objetos. Potencialmente, los sistemas orientados a objetos son capaces de capturar mucho ms del significado de una aplicacin: su semntica. Puesto que los mtodos orientados a objetos tienen como objetivo principal el modelado de sistemas, pueden emplearse para llevar a cabo el modelado de escenarios y facilitar cambios dentro de la empresa. Esta propiedad hace que el producto final sea ms reversible y mejora la posibilidad de efectuar una ingeniera inversa y de retroceder, partiendo de las caractersticas, hasta volver a los requisitos que las originasen. La Uniformidad es la representacin de los objetos que lleva implcita tanto el anlisis como el diseo y la codificacin de los mismos. Los datos que componen los objetos son claros, como los procedimientos que los manipulan, y que estn agrupados en clases, que se corresponden como las estructuras de informacin que el programa trata. Estabilidad. Dado que permiten un tratamiento diferenciado de aquellos objetos permanecen constantes en el tiempo sobre aquellos que tratan con frecuencia, permite aislar las partes del programa que permanecen inalterables en el tiempo. Eliminacin de redundancia. En el desarrollo de sistemas se desea evitar la definicin mltiple de datos y funciones comunes. En POO esto se logra mediante la herencia (evita la definicin mltiple de propiedades comunes a muchos objetos) y el polimorfismo (permite la modificacin de mtodos heredados). Solo hay que definir los atributos y los mtodos en el antepasado ms lejano que los comparte. Las tcnicas orientadas a objetos proporcionan un mecanismo para construir componentes de software reutilizables que posteriormente puedan ser interconectados entre s y formar grandes proyectos de software. Las tcnicas orientadas a objetos ofrecen una alternativa de escribir el mismo programa una y otra vez. El programador orientado a objetos modifica una funcionalidad del programa sustituyendo elementos antiguos u objetos por nuevos objetos, o bien conectando simplemente nuevos objetos en la aplicacin. La reutilizacin de cdigo en reprogramacin tradicional se puede realizar copiando y editando, mientras que en programacin orientada a objetos se puede reutilizar el cdigo, creando automticamente una subclase y anulando alguno de sus mtodos. Referencias