Paradigmas

Modularidad o Un módulo es un grupo de componentes declarados para un propósito común. Estos componen- tes pueden ser tipos, variables, constantes, procedimientos, funciones etc. o Un Módulo encapsula sus componentes. o Permite una interfase con otros módulos y hace conocidos unos pocos componentes hacia fuera del mismo (exportados). o Otros componentes quedan ocultos; asisten a la implementación de componentes exportados. La complejidad del software o Tamaño del software o Hace dos/tres décadas: programas en lenguaje ensamblador en torno a centenares de líneas. o Hoy: lenguajes de alto nivel con centenares de millares, o incluso millones de líneas de código. o Ámbitos de la Complejidad o Complejidad del problema: la implementación se descompone en centenares y a veces miles de módulos independientes que implica tener un equipo de desarrolladores. o Complejidad "humana": cuantos más desarrolladores, las comunicaciones entre ellos son más complejas, la coordinación es difícil: equipos dispersos geográficamente (proyectos grandes) o Sistemas orientados a objetos: o La programación se puede hacer con extensiones de lenguajes comerciales: Object-Pascal o C++, y lenguajes OO puros como Smalltalk y Eiffel. o Aumentan la variedad de aplicaciones que se pueden programar ya que se liberan las restriccio- nes de los tipos de datos predefinidos. o Acomodan estructuras de datos heterogéneos y complejos: se pueden añadir nuevos tipos de da- tos sin modificar código existente. o Propuestas de reutilización (reusability) de componentes software: o Bloques iniciales para la construcción del programa, similares a la construcción de cualquier obje- to complejo (tal como un automóvil) que se construye ensamblando sus partes. POO no sólo son nuevos lenguajes de programación, sino un nuevo modo de pensar y diseñar aplicaciones. Factores de Calidad del software Eficiencia: Capacidad de un software para hacer un buen uso de los recursos que manipula. Transportabilidad (portabilidad) Facilidad con la que un software puede ser transportado sobre diferentes sistemas físicos o lógicos. Verificabilidad (facilidad de verificación) Capacidad para soportar los procedimientos de validación y de aceptar juegos de pruebas o ensayo de programas. Integridad Capacidad de un software a proteger sus propios componentes contra los procesos que no tengan derecho de acceso a ellos. Facilidad de uso Un software es fácil de utilizar si se puede comunicar con él de manera cómoda. Corrección Capacidad de los productos software de realizar exactamente las tareas definidas por su especificación. Robustez Capacidad para funcionar incluso en situaciones anormales. Extensibilidad Facilidad que tienen los productos de adaptarse a cambios en su especificación. Dos principios fundamentales: diseño simple y descentralización. Reutilización Capacidad de los productos de ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones. Compatibilidad Facilidad de los productos para ser combinados con otros. Fundamentos de la Orientación a Objetos o Causas que impulsan el desarrollo de la POO: los mecanismos de encapsulamiento de POO soportan un alto grado de reutilización de código, que se incrementa por sus mecanismos de herencia gran aumento de Lenguajes de Programación Orientados a Objetos (LPOO) implementación de interfaces de usuario gráficos (por iconos) y visuales. o El paradigma OO se revela como el más adecuado para la elaboración del diseño y desarrollo de aplicaciones. o Se caracteriza por la utilización del diseño modular OO y la reutilización del software. o Especial énfasis en la abstracción (capacidad para encapsular y aislar la información del diseño y la ejecución). o Los objetos pasan a ser los elementos fundamentales en este nuevo marco, en detrimento de los subprogramas que lo han sido en los marcos tradicionales Orientación a Objetos Conjunto de disciplinas (ingeniería) que desarrollan y modelan software que facilita la construcción de sistemas complejos a partir de componentes. Trata de cumplir las necesidades de los usuarios finales, y las propias de los desarrolladores de productos software mediante la modelización del mundo real. El soporte fundamental es el modelo de objetos. Los cuatro elementos (propiedades) más importantes de este modelo son: abstracción, encapsulamiento, modularidad y jerarquía. Además de éstas, sue- le incluirse el polimorfismo. Abstracción: o Una abstracción se centra en la vista externa de un objeto o Separar el comportamiento esencial de un objeto de su implementación o Una clase (elemento clave en la POO) es una descripción abstracta de un grupo de obje- tos. Encapsulamiento: o Propiedad que permite asegurar que el contenido de la información de un objeto está oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B y viceversa. o También se conoce como ocultación de la información. o Es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus carac- terísticas esenciales. Modularidad: o propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas mó- dulos), cada una las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. o Consiste en dividir un programa en módulos que se pueden compilar por separado, pero que tienen conexiones con otros módulos. Jerarquía: o Propiedad que permite una ordenación de las abstracciones. o Las dos jerarquías más importantes de un sistema complejo son: generaliza- ción/especialización y agregación. Polimorfismo : o Propiedad que indica la posibilidad de que una entidad tome muchas formas. o Requiere ligadura dinámica o postergada, que sólo se puede producir en lenguajes de programación orientados a objetos. o Ejemplo: la operación calcular perímetro de la clase polígono. Encapsulación Los conceptos estudiados hasta este momento caracterizan a los lenguajes diseñados para la construcción de programas en pequeña escala, dónde las unidades más grandes del programa son fun- ciones y procedimientos. Desde 1970 el diseño de lenguajes apuntó a soportar la programación en grande; construcción de grandes programas a partir de módulos. Un módulo es una unidad de programa que puede implementarse como una entidad más o me- nos independiente. Un módulo bien diseñado tiene un propósito único, y presenta una interfase estrecha a otros módulos. Estos módulos pueden ser reusados, incorporados a otros programas y modificados sin necesidad de realizar mayores cambios a otros módulos. Son importantes dos cuestiones respecto de los módulos: ? Que es lo que hace el módulo? Su propósito. ? Cómo se consigue ese propósito? El "Qué" le interesa al usuario del módulo, el "Cómo" le interesa sólo al implementador del mis- mo. Un módulo es un grupo de varios componentes declarados con un propósito común. Estos componentes pueden ser tipos, constantes, variables, procedimientos, funciones y demás. Se dice que un módulo encapsula sus componentes. Existen varios conceptos importantes que soportan la modularidad: paquetes (package), tipos abstractos, objetos, clases de objetos y genéricos (generics). Paquetes Es un grupo de componentes declarados. En general, los componentes declarados pueden ser tipos, constantes, variables, procedimientos, funciones y sub-paquetes. Un paquetes puede ser visto como un conjunto de enlaces encapsulados. Ocultamiento de Información Comúnmente los paquetes contienen declaración de componentes exportados y ocultos, estos últimos sirven solo para dar soporte a la implementación de los componentes exportados. Tipos abstractos Un tipo abstracto es un tipo definido por un grupo de operaciones. Las operaciones son usual- mente constantes, funciones y procedimientos. El conjunto de valores del tipo se definen indirectamente; consiste de todos los valores que pueden generarse por sucesivas aplicaciones de las operaciones, co- menzando con las constantes. Clases y objetos Otro tipo de módulo muy especial e importante son aquellos que consisten de datos ocultos junto con un conjunto de operaciones exportadas. Los mismos tendrán un tiempo de vida debido a que es un componente variable y se comporta como una variable común. Es importante poder crear clase de objetos similares Abstracciones genéricas Una abstracción genérica es una abstracción sobre una declaración. Quiere decir, una abstracción genérica tiene un cuerpo que es una declaración , y una instanciación genérica es una declaración que producirá enlaces al evaluar el cuerpo de una abstracción genérica. Parametros Type Una declaración también puede hacer uso de tipos definidos previa- mente como parámetros de los mismos. En Ada esto se implementa a través de parámetros Type. Paradigmas de Programación 1 Objeto terno. El elemento primordial del enfoque orientado a objetos es el objeto. Un objeto es una entidad que tiene un conjunto de responsabilidades y que encapsula un estado in- Las responsabilidades (o servicios) que realiza el objeto se implementan mediante métodos, los cua- les describen el comportamiento del objeto. El estado interno del objeto se implementa mediante un con- junto de propiedades o atributos encapsulados. Por lo tanto, los objetos combinan procedimientos y datos en una misma entidad. Un objeto tiene estado, comportamiento y una identidad. El estado del objeto comprende las propiedades estáticas del objeto mas los valores actuales de ca- da una de esas propiedades. Por ej: el objeto CAJA DE AHORRO tiene los atributos número, titular y saldo que constituyen su es- tado interno. Estas son propiedades estáticas. Por otro lado, el contenido actual de cada atributo por ej. (2345/13 'PEDRO' y 1200.56) representan el valor dinámico de sus propiedades, y son afectados por el comportamiento del objeto. El hecho de que cada objeto tiene estado implica que todo objeto ocupa una cierta cantidad de es- pacio, ya sea en el mundo físico o en la memoria de una computadora. El comportamiento de un objeto es como el objeto actúa y reacciona, en términos de sus cambios de estados y de los mensajes que pasa. Es decir que, el comportamiento de un objeto esta completamente definido por sus acciones. Por ej.: el comportamiento del objeto CAJA DE AHORRO esta compuesto por las acciones SALDO, EXTRAER, DEPOSITAR etc. La identidad es la propiedad de un objeto que lo distingue de todos los otros objetos. Por ej.: un objeto CAJA DE AHORRO es distinto de otro objeto CAJA DE AHORRO. Pueden o no te- ner el mismo número, titular o saldo. El primero puede tener como titular a 'PEPE' y el segundo a 'JUAN'. PILA (Tipo abstracto de datos) vacía. Un objeto podría ser una estructura de datos común como lo es una Pila. El comportamiento que tendrá consta de: Agregar o Extraer un elemento, e informar si la pila esta Programa Un programa construido con el modelo de objetos es una colección de objetos cooperantes. La co- operación se lleva a cabo mediante mensajes. Mensaje Un mensaje consiste en el nombre de una operación y de los argumentos por ella requeridos. Los mensajes constituyen el medio por el cual los objetos se comunican con el fin de lograr una ac- ción cooperativa. Cuando un objeto envía un mensaje a otro objeto, el emisor le esta requiriendo al recep- tor que realice la operación nombrada y (posiblemente) devolverle alguna informaci6n. Cuando el receptor recibe el mensaje, realiza la operación requerida en la forma en que sepa hacerla. La petición que hace el emisor no especifica cómo debe ser realizada la operación. Tal información está siempre oculta para el emisor. Abstracción "Una abstracción denota las características esenciales de un objeto que lo distinguen de todas las otras clases de objetos y que por lo tanto proporcionan limites conceptuales bien definidos, con relación a la perspectiva del observador". [Booch] Una abstracción se concentra en la visión exterior de un objeto y, por lo tanto, sirve para separar el comportamiento esencial del objeto de su implementación. La abstracción en otras palabras, captura el comportamiento completo de un objeto, nada más y nada menos. Todas las abstracciones tienen propiedades dinámicas y estáticas. Encapsulamiento Significado del encapsulamiento. La abstracción de un objeto debería preceder las decisiones sobre su implementación. Una vez que una implementación ha sido seleccionada, debería ser tratada como un secreto de la abstracción y permanecer oculta a1 resto de los objetos. Ninguna parte de un sistema comple- jo debería depender de los detalles internos de alguna otra parte. Mientras la abstracción ayuda a la gente a pensar qué es lo que esta haciendo, el encapsulamiento permite que se hagan cambios en los programas en forma confiable y con un esfuerzo limitado. La abstracción y el encapsulamiento son conceptos complementarios, ya que, la abstracción se con- centra en la visión exterior de un objeto y el encapsulamiento evita que los objetos clientes accedan a su visión interna donde el comportamiento de la abstracción es implementado. Para resumir se define encapsulamiento como sigue: "Encapsulamiento es el proceso de esconder todos los detalles de un objeto que no contribuyen a sus características esenciales". [Booch] EJEMPLO 3-1: INTERFACE E IMPLEMENTACION En el ejemplo 1-1 se presenta el objeto VENTANA que representa una ventana de la pantalla. La in- terface externa de este objeto está constituida por los mensajes que el objeto puede recibir del exterior : MOSTRARSE: produce que la ventana se haga visible en la pantalla . OCULTARSE: la ventana se hace invisible. MOVER: la ventana se cambia de ubicación dentro de la pantalla. CAMBIAR COLOR: cambia el color de la ventana. ENCOGERSE: reduce a la mitad las dimensiones de la ventana. EXPANDIRSE: aumenta al doble las dimensiones de la ventana. Para que el objeto pueda responder a estos mensajes necesita tener una implementación constitui- da por un estado interno y de algunos métodos. Habrá una porción de código que conformara el Método para cada mensaje, y el estado interno podría ser : - X, Y : dos enteros que representan las coordenadas del extremo superior izquierdo de la ventana. - ALTO , ANCHO: enteros que representan el alto y el ancho de la ventana. - COLOR BORDE: especificación del color del borde. - TIPO RECUADRO : especificaci6n del tipo de recuadro. Debido al encapsulamiento el estado interno del objeto VENTANA es inaccesible para cualquier otro objeto, esto implica que la única forma de cambiar el tamaño de la ventana sea enviándole el mensaje EXPANDIRSE o el mensaje ENCOGERSE. Suponiendo que el objeto VENTANA estuviera direccionado por la variable unaVentana, el código correspondiente seria: unaVentana.EXPANDIRSE() unaVentana.ENCOGERSE() Pero no seria posible asignar un valor directamente a ANCHO o a ALTO desde afuera del objeto unaVentana. Es decir que un código como el siguiente generaría un error: ALTO:=ALTO / 2 unaVentana.ALTO:= 4 Encapsulamiento también se conoce por el nombre de Information-hiding u ocultación de la infor- mación. Aunque algunos autores establecen una distinción entre estos términos, en el presente trabajo serán tratados como sinónimos. El ocultamiento de la información permite sacar de la vista una porción de aquellas cosas que for- man parte de un objeto. Esto es útil para incrementar los beneficios obtenidos de la abstracción y para dise- ñar código que pueda ser modificado, mantenido y extendido mas fácilmente. El encapsulamiento distingue entre la habilidad para realizar cierta acción y los pasos específicos ne- cesarios para llevarla a cabo. Públicamente, un objeto revela sus habilidades: "Puedo hacer estas cosas" y declara "Puedo contar estas cosas". Pero no cuenta cómo las hace o sabe, ni necesita que otros objetos están al tanto de ello. En cambio, algún otro objeto que le pide una operación o alguna información actúa como un buen gerente. Especifica el trabajo o pide la información y luego se va . No se queda dando vuel- tas viendo como se hace el trabajo o se calcula la información. Es decir que, un objeto mediante su interface hace públicas las acciones que puede realizar y la in- formación que puede devolver, Pero guarda internamente, como un secreto, los detalles de qué métodos o procedimientos ejecuta para llevar a cabo dichas acciones , ni tampoco dice si la información que devuelve es directamente el valor de un atributo o el resultado de una función. Por lo tanto, el objeto cliente que le está requiriendo un servicio no puede hacer ninguna suposición sobre la forma en que el objeto servidor implementa su comportamiento y como consecuencia, el modelo de objetos asegura que la implementación en el objeto cliente es independiente de la implementación del objeto servidor. Esta característica es su- mamente beneficiosa, ya que cualquier cambio en la implementación del objeto servidor (ya sea por mante- nimiento, modificación o extensión) no provocará ningún cambio en el objeto cliente, siempre y cuando no sea necesario modificar la interfaz del servidor. Los objetos solo conocen las operaciones que pueden requerir a otros objetos. Esto ayuda a tomar una visión abstracta del objeto mientras se lo analiza o diseña. Algunos detalles que todavía pueden no ser importantes o desconocidos, pueden ser diferidos para mas adelante en el ciclo de desarrollo. Y entonces es posible concentrarse en la esencia del análisis primero y del diseño después. Otra ventaja aparece mas tarde en la vida del sistema. Se puede cambiar la representación interna de un objeto o implementar un algoritmo superior para una operación especifica sin cambiar la interface pública y abstracta del objeto. Los objetos que dependen de los resultados de las operaciones o de ciertos valores no se ven afectados por el cambio. EJEMPLO 3-2 ENCAPSULAMIENTO Y CAMBIOS EN LA IMPLEMENTACION Supongamos para aprovechar mas velocidad en la graficación, decidiéramos hacer un cambio en el estado interno del objeto VENTANA, de manera que guardara las coordenadas del extremo inferior izquierdo en vez del largo y el ancho. Entonces, el estado interno seria: X , Y , X2 , Y2 , COLOR BORDE TIPO RECUADRO. Este cambio tendría claramente un impacto sobre varios métodos que constituyen la implementación del objeto, como por ejemplo, los métodos que responden a los mensajes MOSTRARSE y ENCOGERSE. Probablemente, la implementación de mostrarse se simplificaría porque no haría falta calcular la otra coor- denada, y la implementación de encogerse seguramente se complicaría por el hecho de tener que calcular el largo y el ancho de la ventana. Una vez realizadas las modificaciones pertinentes en la implementación del objeto, el resto del pro- grama quedaría inalterado, ya que por ejemplo la forma de enviar los mensajes MOSTRARSE y ENCOGERSE no sufriría ningún cambio unaVentana.MOSTRARSE() unaVentana.ENCOGERSE() Esta propiedad del software orientado a objetos, que permite a través del encapsulamiento construir programas mas resistentes al cambio constituye una de las ventajas fundamentales de esta tecnología. Cabe aclarar que en este caso se pudo circunscribir las modificaciones al ámbito de la implementa- ción del objeto, debido a que los cambios introducidos no afectaban la interface publica del objeto. Si hu- biéramos reemplazado por ejemplo los mensajes EXPANDIRSE y ENCOGEPSE por único mensaje REDIMENSIONAR(factor) (si factor > I corresponde expansión, si es menor que 1 se encoge la ventana), habría sido necesario realizar modificaciones en todos los objetos que enviaran los mensajes EXPANDIRSE o ENCOGERSE, cambiando : unaVentana.EXPANDIRSE() por unaVentana.REDIMENSIONAR(2) unaVentana.ENCOGERSE() por unaVentana.REDIMENSIONAR(0.5) El encapsulamiento inteligente localiza las decisiones de diseño que son propensas al cambio. A me- dida que el sistema evoluciona, sus desarrolladores pueden descubrir que en el uso real, ciertas operaciones consumen mas tiempo del aceptable o que ciertos objetos ocupan mayor espacio que el disponible. En tales casos, la representación de un objeto es frecuentemente cambiada de manera que se puedan aplicar algo- ritmos más eficientes o que se ahorre espacio al calcular en vez de almacenar ciertos datos. Esta habilidad para cambiar la representación de una abstracción sin perturbar ninguno de sus clientes es el beneficio esencial del ocultamiento de la información. El encapsulamiento aísla una parte del sistema de otras partes, permitiendo que el código sea modi- ficado y extendido, y que los errores sean corregidos, sin el riesgo de introducir efectos secundarios innece- sarios y no intencionales. Los objetos constituyen la forma de poner este principio en la practica dentro de un programa. 1 - Primero se abstrae la funcionalidad e información relacionada y se la encapsula en un objeto. 2 - Luego se decide qué funcionalidad e información otros objetos requerirán de este objeto, y el re- sto se esconde. Se diseña una interface pública que permita a otros objetos acceder a lo que necesiten, y la representación privada es protegida por defecto del acceso de otros objetos. Clase Se dice que los objetos que comparten el mismo comportamiento pertenecen a la misma clase. Una clase es una especificación genérica para un número arbitrario de objetos similares. Se puede pensar a una clase como un molde para un tipo especifico de objetos; Lo que diferencia a objetos de una misma clase es su identidad y su contenido (datos). Una clase permite construir una taxonomía de objetos a un nivel conceptual y abstracto. Los objetos que se comportan en la forma especificada por una clase se llaman instancias de esa clase. Todos los objetos son instancia de alguna clase. Una vez que se crea la instancia de la clase, se comporta como todas las otras instancias de su clase, capaz de realizar cualquier operación para la cual tenga métodos, inmediatamente después de haber recibido un mensaje. Puede también requerir a otras instancias, ya sea de la misma o de otras clases, que realicen otras operaciones en su nombre. Relaciones entre clases Existen tres tipos de relaciones entre clases Jerárquicas de herencia o de ensamble Contractuales, de colaboración o de asociación: estas relaciones se dan cuando un objeto necesita para poder llevar a cabo su comportamiento un servicio provisto por otro objeto. Jerarquía La abstracción es algo muy bueno, Pero en casi todas las aplicaciones encontramos muchas mas abstracciones (objetos) de las que podemos comprender a la vez. El encapsulamiento ayuda a manejar esta complejidad al esconder la visión interna de las abstracciones. Pero esto no es suficiente. Un conjunto de abstracciones frecuentemente forma una jerarquía identificando estas jerarquías en el análisis y en el dise- ño, se simplifica enormemente el entendimiento del problema. Jerarquía es un ranking u ordenamiento de abstracciones (objetos). parte). Las dos jerarquías más importantes en un sistema complejo son la herencia y el ensamble (todo- La jerarquía de ensamble describe las relaciones de tipo "es parte de" que se dan entre objetos. Básicamente, la herencia define una relación entre clases, donde una clase comparte estructura in- terna y comportamiento definido en una o mas clases (herencia simple y múltiple respectivamente). Por lo tanto, la herencia representa una jerarquía de abstracciones, en la cual una subclase hereda de una o más superclases. Típicamente, una subclase aumenta o redefine la estructura y comportamiento existentes de sus superclases. Herencia El paradigmas de objetos incluye otro mecanismo de abstracción: la herencia. Herencia es un me- canismo que acepta que la definición de una clase incluya el comportamiento y estructura interna definidos en otra clase más general. En otras palabras, se puede decir que una clase es justo como otra clase excep- to que la nueva clase incluye algo extra. La herencia provee un mecanismo para la clasificación, con ayuda de ella se pueden crear taxonomías de clases. La herencia permite concebir una nueva clase de objetos como un refinamiento de otra, con el obje- to de abstraerse de las similitudes entre clases, y diseñar y especificar solamente las diferencias para la clase nueva. De esta manera se pueden crear clases rápidamente. También hace posible la reutilización de código. Las clases que heredan de otras clases pueden heredar comportamiento, frecuentemente una gran cantidad de comportamiento, si la clase o clases de donde heredan fueron diseñadas para poder ser refinadas. Si una clase puede usar algo o todo el código que hereda, no necesita re-implementar esos métodos. Este mecanismo de abstracción puede proveer un modo poderoso de producir código que pueda ser reusado una y otra vez. Subclase es una clase que hereda el comportamiento y estructura interna de otra clase. Una subcla- se generalmente agrega su propio comportamiento y estructura interna para definir su propio y único tipo de objeto. Por ejemplo: suponiendo un sistema que incluye una variedad standard de clases, incluyendo una clase llamada ARRAY permite especificar un numero de elementos, indexarlos, y manipularlos por medio de un índice. Una aplicación puede necesitar una clase para manipular un string de caracteres. Esta clase (que llamaremos STRING) se comporta como un array de caracteres, y entonces heredará de la clase ARRAY de manera que sus elementos puedan ser manipulados a través de un índice. Sin embargo, los strings tienen otra característica, que es la de poder ser comparados y dispuestos en orden alfabético. Por lo tanto, la clase STRING agregara los métodos necesarios para llevar a cabo dicho comportamiento. Se llama superclase a una clase de la cual otras clases heredan su comportamiento y estructura in- terna. Una clase puede tener solo una superclase (herencia simple) o puede tener varias (herencia múlti- ple) combinando comportamiento de varias fuentes y agregando solo un pequeña porción por si sola para producir su propio y único tipo de objeto. En el ejemplo anterior, se puede asumir que la habilidad para comparar dos instancias de una clase, para determinar que una es menor que la otra y ordenar el resultado, esta definida por una clase llamada MAGNITUD. Entonces se podría definir a STRING de manera que también fuera subclase de MAGNITUD y definiendo su orden de modo que fuera alfabético. En ese caso, la clase STRING tendría dos superclases: MAGNITUD y ARRAY. El comportamiento que hereda de ellas tiene que ver con el conocimiento de como comparar y ordenar sus elementos, y como manipularlos a través de índices. El comportamiento que agre- ga tiene que ver con el conocimiento de que el orden es alfabético. Redefinición: Una subclase puede redefinir un método de la superclase simplemente definiendo un método con el mismo nombre. El método en la subclase redefine y reemplaza al método de la superclase. Hay varias razones por las que puede ser útil redefinir un método: para especificar comportamiento que depende de la subclase, para lograr mayor performance a través de un algoritmo más eficiente para la sub- clase o guardando un atributo de calculo dentro de la estructura interna del objeto, etc. Por ejemplo: en una aplicación en la que sea necesario manipular figuras geométricas, podríamos tener la clase POLIGONO y la subclase RECTANGULO, entre otros mensajes tanto un POLIGONO como un RECTANGULO deberían in- formar cual es su perímetro a través del mensaje PERIMETRO. En el caso del polígono se podría implemen- tar como la suma de la longitud de sus lados, mientras que en el rectángulo se podría redefinir el mensaje perímetro para se lo calcule como el doble de la suma de la longitud de dos lados consecutivos. Se pueden redefinir métodos y valores por defecto para los atributos. Toda redefinición debe pre- servar la cantidad o tipo de parámetros utilizados en un mensaje y el tipo del valor devuelto. Nunca debe redefinirse un método de manera que sea semánticamente inconsistente con el originalmente heredado. Una subclase es un caso especial de su superclase y debería ser compatible con ella en todo respecto. Las clases que no han sido creadas para producir instancias de sí mismas se llaman clases abstrac- tas. Existen para que el comportamiento y estructura interna comunes a una determinada variedad de cla- ses pueda ser ubicado en un lugar común, donde pueda ser definido una vez (y más tarde, mejorado o arreglado de una sola vez, sí es necesario), y reusado una y otra vez. Las clases abstractas especifican en forma completa su comportamiento pero no necesitan estar completamente implementadas. Puede también especificar métodos que deban ser redefinidos por cualquier subclase. Un ejemplo de esto puede ser la implementación de cierto comportamiento por defecto para prevenir un error del sistema, pero dicha im- plementación debe ser redefinida o aumentada por los métodos implementados en las subclases. La jerarquía de herencia es también conocida como jerarquía de generalización/especialización. Es- tos tres términos se refieren a aspectos de la misma idea y frecuentemente son utilizados indistintamente. Se utiliza generalización para referirse a la relación entre clases, mientras que herencia se refiere al meca- nismo de compartir atributos y métodos utilizando la relación de generalización. Generalización y especiali- zación corresponden a dos puntos de vista diferentes de la misma relación, desde la perspectiva de las su- perclases o de las subclases. La palabra generalización deriva del hecho de que la superclase generalice las subclases. Especialización se refiere al hecho de que las subclases refinan o especializan la superclase. En la practica mas allá de esta distinción teórica estos términos serán usados indistintamente. A medida que la jerarquía de herencia, evoluciona, la estructura interna y el comportamiento que son iguales para clases diferentes tenderá a migrar hacia superclases comunes. Este es el motivo por el cual se dice que la herencia es una jerarquía de generalización/especialización. Las superclases representan abs- tracciones generalizadas, y las subclases representan especializaciones en las cuales campos y métodos de la superclase son agregados, modificados o aun ocultados. De este modo la herencia permite establecer las abstracciones con una economía de expresión. Hace posible definir software nuevo de la misma forma en que le introducimos conceptos a los novatos, comparándolos con algo que ya les sea familiar. Ensamble Ensamble es la relación "todo-parte" o "es parte de" en la cual los objetos que representan los com- ponentes de algo son asociados a un objeto que representa el todo. [Rumbaugh] La jerarquía de ensamble describe las relaciones de tipo "es parte de" que se dan entre objetos, es decir que identifica cada una de las partes que componen un objeto Polimorfismo Polimorfismo se aplica a una operación que adopta varias formas de implementación. Es la habilidad de dos o mas objetos de responder a un mismo mensaje, cada uno de su propia forma. Esto significa que un objeto no necesita saber a quien le esta enviando un mensaje. Solo debe saber que se han definido varios tipos diferentes de objetos para que respondan a ese mensaje en particular. Ejemplos: En el caso del POLIGONO y el RECTANGULO (Rectángulo es una subclase de Polígono) ambas clases responden al mensaje PERIMETRO devolviendo un número que representa el perímetro de la figura. Ambos, objetos responden al mismo mensaje y cada uno lo hace de la manera que es mas apropia- da. Por ello, al escribir una porción de código en la que se necesita saber el perímetro de una figura solo hace falta enviar el mensaje PERIMETRO sin preocuparnos si el objeto es una instancia de la clase POLIGONO o de la clase RECTANGULO. Otro caso de Polimorfismo podría darse en un sistema bancario, donde tanto la clase CUENTA- CORRIENTE como la clase CAJA-DE-AHORRO responden a los mensajes EXTRAER(monto) o SALDO(). Objetos de una variedad de diferentes, pero similares, clases pueden reconocer algunos mismos mensajes y responder en forma similar y apropiada. Una respuesta apropiada para una clase de objeto podría ser completamente inapropiada para otra clase. El emisor no necesita preocuparse por el método que se ejecuta como resultado del envío del mensaje. El Polimorfismo permite reconocer y explotar las similitudes entre diferentes clases de objetos. Cuando reconocemos que varios tipos diferentes de objetos pueden responder al mismo mensaje, estamos reconociendo la distinción entre el nombre del mensaje y un método. Un objeto envía un mensaje: si el receptor implementa un método que corresponde al mensaje, responderá. Diferentes respuestas son posi- bles, por lo tanto métodos diferentes tienen sentido para clases diferentes, pero el emisor puede simple- mente enviar el mensaje sin preocuparse de la clase del receptor. Un concepto relacionado al de Polimorfismo es el de Binding dinámico: significa que el enlace entre el receptor del mensaje, y el mensaje, se realiza en forma dinámica (en tiempo de ejecución). Ciclo de Desarrollo en el Paradigma de Objetos El enfoque tradicional para el desarrollo de software es un proceso secuencial llamado frecuente- mente "modelo en cascada". Este ciclo de vida esta compuesto por cuatro etapas: análisis, diseño, codifica- ción y prueba. El proceso se lleva a cabo en secuencia y cada etapa comienza solo cuando la anterior ha sido finalizada. Solo cuando la ultima etapa haya terminado se podrá instalar el sistema. Los problemas de aplicar rígidamente este enfoque son bien conocidos: El modelo de cascada asume una progresión relativamente uniforme de las etapas de elaboración. Se asume que el análisis de requerimientos inicial no tiene error, y una vez que ha sido hecho el re- sto de las etapas fluirán en forma natural. Pero en el mundo real, entender los requerimientos de un siste- ma no es tarea fácil y generalmente el análisis inicial tiene que ser revisado y modificado. La participación del usuario final es pobre. El sistema se transforma en inteligible para el usuario en la etapa de diseño cuando sus requerimientos se traducen en especificaciones técnicas. El resultado es que el cliente no puede validar el diseño hasta que el producto este completo, entonces se pueden llegar a pro- ducir programas que no cumplan completamente con las necesidades del usuario final. El diseño y la codificación se derivan del análisis inicial, de manera que son específicos para los re- querimientos de determinada aplicación. Por lo tanto, el enfoque tradicional tiende a no reusar código exis- tente. Esto provoca duplicación de esfuerzo y reducción de productividad. Los sistemas se construyen de manera que los diferentes componentes (subsistemas, módulos, pro- gramas) son muy interdependientes, como lo son programas y datos. Esto hace difícil las modificaciones y el mantenimiento. Por ejemplo, para agregar una nueva función o cambiar el formato de algún dato hace falta modificar varios programas en diferentes lugares y después, pasar por largas compilaciones y pruebas. Por lo tanto, los cambios en los requerimientos del negocio o las nuevas oportunidades de hardware o soft- ware no pueden ser fácilmente explotadas. El modelo de cascada no se adapta al desarrollo de tipo evolucionario que se hace posible con la prototipación rápida y con los lenguajes de cuarta generación. Si bien, cuando se trabaja con orientación a objetos se puede utilizar el modelo de cascada, es re- comendable y hasta mas natural recurrir a otros ciclos de desarrollo de tipo iterativa (como el espiral de Boehm) o a la prototipación rápida. El ciclo de desarrollo orientado a objetos, en contraposición con el modelo secuencial de cascada, enfatiza la idea de que el proceso de desarrollo real consiste de una serie de iteraciones en cada una de las etapas del proceso. En vez de ser un proceso secuencial es un enfoque "circular" en el cual se comple- tará el sistema luego de un cierto número de iteraciones. El análisis comienza con una porción del sistema que pasa luego por diseño, implementación y prueba, avanzando luego a otra fase de análisis para comenzar una nueva iteración. Al pasar por cada itera- ción el sistema va evolucionando. Este proceso se detiene cuando el sistema esta lo suficientemente madu- ro como para cumplir con los requerimientos eficientemente. Una porción más grande del tiempo es utilizada en el diseño. Esto es, porque el software se esta di- señando para ser fácilmente reusado, mantenida y modificado. Las herramientas de programación orienta- das a objetos no aseguran, por si mismas, la reusabilidad, mantenibilidad y extensibilidad del software. Ni tampoco son, de hecho, absolutamente necesarias. Sin embargo, las herramientas de programación orien- tadas a objetos pueden ayudar en un proyecto en el cual los miembros del equipo dediquen su tiempo a explorar el problema y hacer un diseño cuidadoso. Un gran esfuerzo es necesario para diseñar código para reusar, pero es un esfuerzo que paga generosamente al final. El tiempo utilizado en realizar un diseño cuidadoso permite entender el problema profundamente. La implementación se acelera porque se ha aprendido bastante sobre el problema. Por lo tanto, el tiempo total requerido para un ciclo puede permane- cer sin cambios o aún disminuir. Y como el software fue diseñado desde el principio teniendo en mente el mantenimiento, la extensión, la reusabilidad, el tiempo requerido para cualquier esfuerzo subsiguiente de- crece radicalmente. Objetivos de la Orientacion a Objetos La introducción de la tecnología de objetos en el desarrollo de software responde a los siguientes objetivos: Favorecer la productividad: promoviendo la reusabilidad como una meta primordial, proveyendo herramientas mas adecuadas para modelizar el mundo real y permitiendo la utilización de ciclos de desarro- llo mas flexibles. Incrementar la calidad: la utilización de componentes reusables produce sistemas mas robustos, de- bido a que cada componente al haber sido usado varias veces ha sido sometido a muchas pruebas y por lo tanto, tiene una confiabilidad mayor. Por otra parte, al ser posible corregir errores cometidos en etapas iniciales con relativa facilidad, se logra que los sistemas orientados a objetos sean mas resistentes al cam- bio, un aspecto de la calidad que será preponderante en la computación del futuro. Mejorar el mantenimiento: debido a que los requerimientos de un sistema se encuentran en estado de cambio permanente, la clave para lograr un mejor mantenimiento se encuentra en desarrollarlo de manera que se le puedan incorporar suavemente los cambios que no puedan ser anticipados. La manera de lograrlo es separando las partes del sistema que son intrínsecamente volátiles de las que son mas esta- bles. Las técnicas estructuradas no logran este objetivo y por lo tanto, necesitan imponer un congelamiento de los requerimientos del sistema. El paradigmas de objetos considera en cambio al sistema en su evolu- ción en el tiempo y provee herramientas para soportar un ciclo de desarrollo evolutivo. Ventajas de la Orientación a Objetos Mayor modularidad al encapsularse funcionalidad en objetos. Mayor extensibilidad debido a la modularidad y a la utilización de la herencia combinada con poli- morfismo. Desarrollo de software mas reusable. Simplicidad de diseño. Software modificable con mayor facilidad. Mejor comprensión del mundo de las aplicaciones. Utilización de ciclos de desarrollo mas flexibles que el tradicional de cascada. Incrementa la consistencia entre análisis, diseño y programación, debido a que se elimina los "sal- tos" entre estas etapas. Continuidad en la representación desde el análisis, pasando por el diseño hasta la programación: el modelo que resulta del análisis se expande en el diseño y luego en la programación, pero en ningún mo- mento hace falta cambiar el tipo de modelo (como la conversión del DFD a los diagramas de estructura, en las técnicas estructuradas). Problemas con la Orientación a Objetos Falta de consenso respecto de metodologías de desarrollo. Necesidad de capacitar y producir un cambio cultural en el equipo de sistemas: nuevas y diferentes metodología de desarrollo, herramientas de programación, roles que cumplir, etc. Necesidad de establecer una metodología para administrar la reusabilidad.